# Webscale Product Documentation - Complete Documentation
> Comprehensive documentation for building, deploying, and managing your infrastructure, applications, and security with Webscale Networks.

This document contains the complete documentation for Webscale Product Documentation except
for the [Webscale API](https://docs.webscale.com/docs/api/), which is independently
generated and whose OpenAPI specification is at
https://control.webscale.com/docs/openapi.json.

---
# 2026.40
URL: https://docs.webscale.com/docs/reference/images/2026.40/
Description: Released 2026-08-21


## Changes

### V4: pass environment to web server

The environment provided to containers running in a V4 web server image can now
receive environment variables through cluster metadata by specifying a set of
space-separated metadata keys in a metadata entry `CONTAINER_ENVIRONMENT`.

### Essentials: Vinyl bypass

The relay proxy on essentials servers has been updated to bypass the
Vinyl cache entirely if either of `Range` or `Bypass-Vinyl` headers are
included in a request.

### V4: New web-server-php stack

A new stack, `web-server-php` is now supported in the `web-server-v4` image
family that will run php code in containers using a Symfony type front
controller dispatch. A container image is specified by configuration of a
cluster but defaults to displaying the system welcome page.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.40  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.40  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.40  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.24<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.40  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.9<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.40  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.40    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.40    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.40    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.24<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.40    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.40        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.40        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.40        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.24<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.40        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.40           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.40            |
---
# 2026.39
URL: https://docs.webscale.com/docs/reference/images/2026.39/
Description: Released 2026-08-18


## Changes

### Always build containers with latest New Relic

Previously, the New Relic PHP agent installed on container images was
fixed at a specific version and periodically updated, last to 12.4.0.29.
This change updates the agent install to always use the latest version,
currently 12.9.0.38.

### Manage service dependencies within stacker

For the V4 web server image family, this change moves the responsibility for
managing `/share/www` mount dependencies from a systemd stacker service
declaration to a stack resource definition using a new `required_services`
declaration. During resource configuration, a required resource is started as
necessary until it becomes active. This occurs in an infinite loop with a small
delay to recover from transient that might occur during unit start. This
creates the possibility for a stack based on a web server image that does not
require a `/share/www` directory.

### Essentials: Fix file descriptor exhaustion

The php-fpm relay ran out of file descriptors on an essentials system after
enabling Vinyl, repeating the messsage `dial unix /run/php-fpm.sock: connect:
resource temporarily unavailable` in the `php-fpm` unit logs. Two factors
contributed to this problem. First, poor tuning of the Vinyl proxy led to
connections to the Vinyl server being closed almost immediately after use,
leading to port exhaustion as connections were held in TIME_WAIT. Second, a
deadlock could occur when a client closed a connection early without waiting
for a complete response, leaving a connection and its associated file
descriptors forever held. Both of these issues have been addressed in this
change.

### Essentials: Vinyl client commands

Commands `varnishadm`, `varnishhist`, `varnishlog`, `varnishstat`, and
`varnishtop` are now available on the core server.

### Support for web-server stack

Two new services added to `webscale-web-server` package: `web-server` and
`relay`. The web server service simply launches the container provided in the
cluster server metadata. The relay service, in this case, runs on the host and
routes port 80 traffic to the container listening on port 3000. Providing a
value for metadata key `CONTAINER_HTTP_PORT` is used to override the container
port.

### Add Elasticsearch plugin support

When the `webscale-opensearch` is installed and configured for the
`elasticsearch` variant, `OPENSEARCH_PLUGINS` can be used to install plugins
at startup as is already supported for OpenSearch.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| RabbitMQ  | 4.3.4    | 4.3.5   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.39  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.39  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.39  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.24<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.39  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.9<br>composer-2.10.2<br>newrelic 12.9.0.38 | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.39  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.39    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.39    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.39    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.24<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.39    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.39        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.39        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.33<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.39        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.24<br>composer-2.10.2<br>newrelic 12.9.0.38 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.39        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.39           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.39            |
---
# 2026.38
URL: https://docs.webscale.com/docs/reference/images/2026.38/
Description: Released 2026-08-11


## Changes

### Allow V3 web-server to mount V4 core share

This adds a `share-www.mount` unit that can be enabled with
`command.EnableService` that will mount a V4 core server share defined in the
same VPC at `/share/www`.

### Allow username and password to be omitted for AWS ECR

Previously, although the ECR credential helper was installed and the
AWS instance profile was granted authority to pull images by obtaining
a password, the `ContainerRun` command required an explicit username
and password. This in turn required it be preceded by a
`PrepareEcrLoginPassword`, because the credentials have a short
lifespan. This was needless, tedious configuration. A `ContainerRun`
command can now omit the `username` and `password` parameters, in which
case an image pull to an authorized registry is handled automatically.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.38  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.33, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.38  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.33, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.38  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.24, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.38  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.9, composer-2.10.2     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.38  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.38    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.38    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.38    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.24, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.38    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.38        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.38        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.38        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.24, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.38        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.38           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.38            |
---
# 2026.37
URL: https://docs.webscale.com/docs/reference/images/2026.37/
Description: Released 2026-08-11


## Changes

This release contains only internal changes.
## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.37  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.33, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.37  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.33, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.37  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.24, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.37  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.9, composer-2.10.2     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.37  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.37    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.37    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.37    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.24, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.37    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.37        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.37        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.37        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.24, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.37        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.37           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.37            |
---
# 2026.36
URL: https://docs.webscale.com/docs/reference/images/2026.36/
Description: Released 2026-08-10


## Changes

### V3: Supervisor support on web-server

It is apparently typical practice to create cron servers and supervisor
servers with clusters based on a `web-server` image. Therefore, this
release adds the supervisor shims that are included in the `nfs-server`
image as an optional service. Configuration files may be placed in the
host `/etc/supervisor` directory and are normally expected to be placed
there by the invoker bootstrap sequence. A new `command.EnableService`
invoker command accepting a `name` parameter can be used to enable
a systemd service such as `supervisor`. To use supervisor in this way,
it is required that the image for a cluster is configured via cluster
attributes so that the `CONTAINER_IMAGE_URI` metadata variable is set.

### V3: shell command on web-server

Supervisor is run through the `shell` command, which is now provided
on web servers. For mapping network shared files into the shell, the
metadata variables `WEBSCALE_SHARE` and `WEBSCALE_SHARED_DIRS` is used
to set the directory where the file system is mounted and a space-
separated set of subdirectories (or files) that are mapped into the
shell. For example, `/var/www/shared/mysite.com` and `pub/media var`
are usual, respective values. Note that unlike `V4` systems, the `html`
prefix is *not* included and it is not possible to share at the top
level.

### V3: Invoker configuration from metadata

This release adds a metadata variable `WEBSCALE_BOOTSTRAP` that specifies a
locator for a bootstrap sequence. In combination with metadata variables
`WEBSCALE_CUSTOMER` and `WEBSCALE_ENVIRONMENT`, it is no longer necessary to
write any files to the file system (as was formerly done in a cloud-init
script).

### Datadog collector

The Datadog collector is now added to all images and can be enabled
by defining metadata variable `DATADOG_API_KEY` or by providing file
`/etc/datadog-agent/datadog.yaml`.

### New tools

New tools are added to all images:

- `btop`: Command line resource monitor
- `mtr-tiny`: Full screen ncurses traceroute tool
- `ncdu`: Disk usage viewer
- `psmisc`: Proc file system utilities
- `rclone`: Rsync for commercial cloud storage
- `ripgrep`: Recursively searches directories for a regex pattern
- `wget`: Retrieves files from the web

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| PHP       | 8.2.32   | 8.2.33  |
| PHP       | 8.3.32   | 8.3.33  |
| PHP       | 8.4.23   | 8.4.24  |
| PHP       | 8.5.8    | 8.5.9   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.36  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.33, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.36  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.33, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.36  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.24, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.36  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.9, composer-2.10.2     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.36  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.36    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.36    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.36    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.24, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.36    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.36        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.36        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.33, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.36        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.24, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.36        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.36           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.36            |
---
# 2026.35
URL: https://docs.webscale.com/docs/reference/images/2026.35/
Description: Released 2026-08-07


## Changes

### Prevent private networks from SSHGuard block

Requests from networks `10.0.0.0/8`, `172.16.0.0/12`, and
`192.168.0.0/16` will no longer be blocked by SSHGuard.

### V4 essentials: Fix default.vcl is overwritten by stacker

For an essentials server, the file `/etc/vinyl/default.vcl` is meant to
be populated by the stack and made writable by the `dev` group on
initial install and then not touched afterward.  Instead, it was being
treated as a template and overwritten on each execution of stacker and
without the permissions being set correctly. This change corrects the
handling to install the file only on the initial run.

### V4: Fix core server root disk fills up

As images are changed and used as part of `dev` or cron execution, they
are not pruned by the default image pruner because it only functions if
docker is installed. This creates a core server pruner that runs hourly
that prunes all unused images except the one currently in use.

### Fix logrotate package mistakenly omitted

Since 2026.29 logrotate was not automatically included in the web-server and
nfs-server builds because "recommended" packages are no longer automatically
installed. This change updates the server init script so that all images will
now contain logrotate.

### Add eu-west-3 as a sharing region for images

### Add OpenSearch plugin support

Adds support for installing OpenSearch plugins at container startup via
a custom entrypoint script. Plugins listed in `OPENSEARCH_PLUGINS` in
`/etc/opensearch/env` are installed on startup if not already present.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.35  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.32, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.35  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.32, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.35  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.23, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.35  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.8, composer-2.10.2     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.35  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.35    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.35    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.35    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.23, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.35    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.35        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.35        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.35        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.23, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.35        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.35           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.35            |
---
# 2026.34
URL: https://docs.webscale.com/docs/reference/images/2026.34/
Description: Released 2026-07-21


## Changes

### Simplify image sharing

Images are now shared within the Webscale Networks AWS organization directly
instead of account by account, simplifying image access for new accounts.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Debian    | 12.14    | 12.15   |
| Debian    | 13.5     | 13.6    |
| PHP       | 8.2.31   | 8.2.32  |
| PHP       | 8.3.31   | 8.3.32  |
| PHP       | 8.4.22   | 8.4.23  |
| PHP       | 8.5.7    | 8.5.8   |
| RabbitMQ  | 4.3.2    | 4.3.3   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.34  |
| Container  | php-fpm:8.2-arm64 | Debian 13.6          | 8.2.32, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.34  |
| Container  | php-fpm:8.3-arm64 | Debian 13.6          | 8.3.32, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.34  |
| Container  | php-fpm:8.4-arm64 | Debian 13.6          | 8.4.23, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.34  |
| Container  | php-fpm:8.5-arm64 | Debian 13.6          | 8.5.8, composer-2.10.2     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.34  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.34    |
| Container  | php-fpm:8.2-deb   | Debian 13.6          | 8.2.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.34    |
| Container  | php-fpm:8.3-deb   | Debian 13.6          | 8.3.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.34    |
| Container  | php-fpm:8.4-deb   | Debian 13.6          | 8.4.23, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.34    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.34        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.34        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.32, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.34        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.23, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.34        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.3                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.34           |
| Container  | varnish           | Debian 12.15         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.34            |
---
# 2026.33
URL: https://docs.webscale.com/docs/reference/images/2026.33/
Description: Released 2026-07-01


## Changes

### New Pro Magento V4 stack

This adds hosting image support for the `pro-magento-v4` stack type.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Composer  | 2.10.1   | 2.10.2  |
| Alpine    | 3.24.0   | 3.24.1  |
| RabbitMQ  | 4.3.1    | 4.3.2   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.33  |
| Container  | php-fpm:8.2-arm64 | Debian 13.5          | 8.2.31, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.33  |
| Container  | php-fpm:8.3-arm64 | Debian 13.5          | 8.3.31, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.33  |
| Container  | php-fpm:8.4-arm64 | Debian 13.5          | 8.4.22, composer-2.10.2    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.33  |
| Container  | php-fpm:8.5-arm64 | Debian 13.5          | 8.5.7, composer-2.10.2     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.33  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.33    |
| Container  | php-fpm:8.2-deb   | Debian 13.5          | 8.2.31, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.33    |
| Container  | php-fpm:8.3-deb   | Debian 13.5          | 8.3.31, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.33    |
| Container  | php-fpm:8.4-deb   | Debian 13.5          | 8.4.22, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.33    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.33        |
| Container  | php-fpm:8.2       | Alpine 3.24.1        | 8.2.31, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.33        |
| Container  | php-fpm:8.3       | Alpine 3.24.1        | 8.3.31, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.33        |
| Container  | php-fpm:8.4       | Alpine 3.24.1        | 8.4.22, composer-2.10.2    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.33        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.2                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.33           |
| Container  | varnish           | Debian 12.14         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.33            |
---
# 2026.32
URL: https://docs.webscale.com/docs/reference/images/2026.32/
Description: Released 2026-06-10


## Changes

### Varnish transient memory

Update varnish to use 1/8th of overall system memory for the transient
pool, increased from a fixed 1GB.

### Opensearch network access

Fix the opensearch binding to always use host networking, for both the
essentials systems and those where `webscale-opensearch` is installed. This
avoids a problem where podman does not create the correct nftables rules.

### Core server image on Standard V4

Add a new `image-monitor` unit to the core server that allows it to receive the
same image as an associated cluster so that it can be used to run cron, for
example.

### Remove dotfiles restriction

Update the relay proxy to no longer exclude all dot files from being served, but
only `.git`, `.htpasswd`, `.htaccess`, `.user.ini`, and `.env`.

### Debian packaging version numbering

Update the versions numbering scheme of the debian packages to drop the constant
`.0` suffix.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.32  |
| Container  | php-fpm:8.2-arm64 | Debian 13.5          | 8.2.31, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.32  |
| Container  | php-fpm:8.3-arm64 | Debian 13.5          | 8.3.31, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.32  |
| Container  | php-fpm:8.4-arm64 | Debian 13.5          | 8.4.22, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.32  |
| Container  | php-fpm:8.5-arm64 | Debian 13.5          | 8.5.7, composer-2.10.1     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.32  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.32    |
| Container  | php-fpm:8.2-deb   | Debian 13.5          | 8.2.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.32    |
| Container  | php-fpm:8.3-deb   | Debian 13.5          | 8.3.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.32    |
| Container  | php-fpm:8.4-deb   | Debian 13.5          | 8.4.22, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.32    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.32        |
| Container  | php-fpm:8.2       | Alpine 3.24.0        | 8.2.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.32        |
| Container  | php-fpm:8.3       | Alpine 3.24.0        | 8.3.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.32        |
| Container  | php-fpm:8.4       | Alpine 3.24.0        | 8.4.22, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.32        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.1                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.32           |
| Container  | varnish           | Debian 12.14         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.32            |
---
# 2026.31
URL: https://docs.webscale.com/docs/reference/images/2026.31/
Description: Released 2026-06-10


## Changes

### New webscale-valkey package

A new `webscale-valkey` package is added to the `webscale` debian
repository that allows `valkey` to be used on NFS servers.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Composer  | 2.9.8    | 2.10.1  |
| PHP       | 8.4.21   | 8.4.22  |
| PHP       | 8.5.6    | 8.5.7   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.31  |
| Container  | php-fpm:8.2-arm64 | Debian 13.5          | 8.2.31, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.31  |
| Container  | php-fpm:8.3-arm64 | Debian 13.5          | 8.3.31, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.31  |
| Container  | php-fpm:8.4-arm64 | Debian 13.5          | 8.4.22, composer-2.10.1    | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.31  |
| Container  | php-fpm:8.5-arm64 | Debian 13.5          | 8.5.7, composer-2.10.1     | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.31  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.31    |
| Container  | php-fpm:8.2-deb   | Debian 13.5          | 8.2.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.31    |
| Container  | php-fpm:8.3-deb   | Debian 13.5          | 8.3.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.31    |
| Container  | php-fpm:8.4-deb   | Debian 13.5          | 8.4.22, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.31    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.31        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.31        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.31, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.31        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.22, composer-2.10.1    | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.31        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.1                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.31           |
| Container  | varnish           | Debian 12.14         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.31            |
---
# 2026.30
URL: https://docs.webscale.com/docs/reference/images/2026.30/
Description: Released 2026-05-27


## Changes

### Standard Magento stack improvements

- Opensearch and Valkey instances are properly bound to allow external network
  traffic.
- The `html/app/etc` directory can be included in the `share` variable, allowing
  it to be shared and the automatic configuration to be suppressed.
- An authorization bug preventing the `php-fpm` service from starting has been
  fixed.
- A default `/etc/php/env.php` is made available and can be incorporated into
  a site `env.php` using `array_replace_recursive`.
- An error causing the `/etc/php/registry-auth.json` to fail to generate
  has been corrected.
- An issue with the relay proxy using the wrong document root has been
  corrected. It also now prints additional information about its config
  at startup in its log.
- Stack definitions now include default variable values.
- The relay proxy now runs within the php-fpm container context to simplify
  file system access.
- The relay proxy uses a specific Magento behavior module that provides
  greater fidelity to Magento requirements. Similar modules for Symfony
  (Shopware), and Wordpress are also included.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| RabbitMQ  | 4.3.0    | 4.3.1   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.30  |
| Container  | php-fpm:8.2-arm64 | Debian 13.5          | 8.2.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.30  |
| Container  | php-fpm:8.3-arm64 | Debian 13.5          | 8.3.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.30  |
| Container  | php-fpm:8.4-arm64 | Debian 13.5          | 8.4.21, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.30  |
| Container  | php-fpm:8.5-arm64 | Debian 13.5          | 8.5.6, composer-2.9.8      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.30  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.30    |
| Container  | php-fpm:8.2-deb   | Debian 13.5          | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.30    |
| Container  | php-fpm:8.3-deb   | Debian 13.5          | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.30    |
| Container  | php-fpm:8.4-deb   | Debian 13.5          | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.30    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.30        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.30        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.30        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.30        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.1                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.30           |
| Container  | varnish           | Debian 12.14         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.30            |
---
# 2026.29
URL: https://docs.webscale.com/docs/reference/images/2026.29/
Description: Released 2026-05-21


## Changes

### Fix CONTAINER_IMAGE_URI not propagated

Previously, when `CONTAINER_IMAGE_URI` metadata is set on a cluster, it was not
propagated to the web server stack, and instead the default base image was run.
This change updates stack variable processing, making metadata available and
updates the php-fpm template to use `CONTAINER_IMAGE_URI` if it is present.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.29  |
| Container  | php-fpm:8.2-arm64 | Debian 13.5          | 8.2.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.29  |
| Container  | php-fpm:8.3-arm64 | Debian 13.5          | 8.3.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.29  |
| Container  | php-fpm:8.4-arm64 | Debian 13.5          | 8.4.21, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.29  |
| Container  | php-fpm:8.5-arm64 | Debian 13.5          | 8.5.6, composer-2.9.8      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.29  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.29    |
| Container  | php-fpm:8.2-deb   | Debian 13.5          | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.29    |
| Container  | php-fpm:8.3-deb   | Debian 13.5          | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.29    |
| Container  | php-fpm:8.4-deb   | Debian 13.5          | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.29    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.29        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.29        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.29        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.29        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.29           |
| Container  | varnish           | Debian 12.14         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.29            |
---
# 2026.28
URL: https://docs.webscale.com/docs/reference/images/2026.28/
Description: Released 2026-05-21


## Changes

### Mitigation for CVE-2026-46333

This release includes mitigation for CVE-2026-46333, disabling ptrace for
non-root users.

### Relay proxy improvements

Updates to the relay proxy for essentials and standard stacks. This allows for
Wordpress to be installed at /var/www/html.

### Fix bad permissions for opensearch

Updates to the nfs-server `fix-shared-permissions` command to exclude opensearch
and redis directories.

### PHP logging improvements

Use `REQUEST_URI` instead of `%r%Q%q` for URI logging in PHP-FPM container logs.
This avoids the problem of all logs containing the path of the front controller
(usually `/index.php`).

### Reduced PHP attack surface

Setting `cgi.fix_pathinfo = 0` for essentials and standard packages. This
disallows old-style PHP paths such as `/entry.php/some/path`, which are not
expected to be used in modern environments.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Debian    | 13.4     | 13.5    |
| Varnish   | 6.0.17   | 6.0.18  |
## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.28  |
| Container  | php-fpm:8.2-arm64 | Debian 13.5          | 8.2.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.28  |
| Container  | php-fpm:8.3-arm64 | Debian 13.5          | 8.3.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.28  |
| Container  | php-fpm:8.4-arm64 | Debian 13.5          | 8.4.21, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.28  |
| Container  | php-fpm:8.5-arm64 | Debian 13.5          | 8.5.6, composer-2.9.8      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.28  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.28    |
| Container  | php-fpm:8.2-deb   | Debian 13.5          | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.28    |
| Container  | php-fpm:8.3-deb   | Debian 13.5          | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.28    |
| Container  | php-fpm:8.4-deb   | Debian 13.5          | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.28    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.28        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.28        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.28        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.28        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.28           |
| Container  | varnish           | Debian 12.14         | 6.0.18                     | arm64 | public.ecr.aws/webscale/varnish:2026.28            |
---
# 2026.27
URL: https://docs.webscale.com/docs/reference/images/2026.27/
Description: Released 2026-05-14


## Changes

### Mitigate CVE-2026-42945

This release includes an update to nginx 1.24.0-2ubuntu7.8 for relevant
images to prevent the attack described in CVE-2026-42945.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.27  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.27  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.27  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.21, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.27  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.6, composer-2.9.8      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.27  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.27    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.27    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.27    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.27    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.27        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.27        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.27        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.27        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.27           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.27            |
---
# 2026.26
URL: https://docs.webscale.com/docs/reference/images/2026.26/
Description: Released 2026-05-13


## Changes

### Mitigate CVE-2026-43284 and CVE-2026-43500

This release includes mitigation for CVE-2026-43284 and CVE-2026-43500, aka
["Dirty Frag"](https://github.com/V4bel/dirtyfrag).

### Relay proxy dropped connection fix

Improvements are made in error recovery for the relay proxy when clients close
connections. Previously, when a client closed a connection, it could result in
connection in an inconsistent state. Then subsequent requests could attempt to
use the connection and fail because the state maintained by the proxy server was
not consistent with the state of the connection in PHP-FPM. This change causes a
FastCGI abort to be used when a client terminates a connection early, releasing
PHP-FPM resources as early as possible and preventing connection reuse.

### New "Standard Magento" stack

This release introduces a new `web-server-v4` image family. Note that this
family is not compatible with images in the invoker based `web-server` and they
must not be considered interchangeable.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| PHP       | 8.2.30   | 8.2.31  |
| PHP       | 8.3.30   | 8.3.31  |
| PHP       | 8.4.20   | 8.4.21  |
| PHP       | 8.5.5    | 8.5.6   |
| Composer  | 2.9.7    | 2.9.8   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.26  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.26  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.31, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.26  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.21, composer-2.9.8     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.26  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.6, composer-2.9.8      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.26  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.26    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.26    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.26    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.26    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.26        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.26        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.31, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.26        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.21, composer-2.9.8     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.26        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.26           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.26            |
---
# 2026.25
URL: https://docs.webscale.com/docs/reference/images/2026.25/
Description: Released 2026-04-29


## Changes

### Mitigate CVE-2026-31431

This change mitigates the local privilege escalation vulnerability registered
as CVE-2026-31431 and documented with an exploit at https://copy.fail/.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.25  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.25  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.25  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.20, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.25  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.5, composer-2.9.7      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.25  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.25    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.25    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.25    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.25    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.25        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.25        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.25        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.25        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.25           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.25            |
---
# 2026.24
URL: https://docs.webscale.com/docs/reference/images/2026.24/
Description: Released 2026-04-29


## Changes

### Add custom image support to essentials

Essentials servers have been fitted with optional PHP-FPM custom image
support.  By placing a Dockerfile at `/etc/php/image/Dockerfile` and
running the `build-php-image` command, a custom image is created that
will be used for the `dev` environment and the `php-fpm` service. The
image may be updated at any time by repeating the command, which will
update the configuration and reload php-fpm.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.24  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.24  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.24  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.20, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.24  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.5, composer-2.9.7      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.24  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.24    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.24    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.24    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.24    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.24        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.24        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.24        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.24        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.24           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.24            |
---
# 2026.23
URL: https://docs.webscale.com/docs/reference/images/2026.23/
Description: Released 2026-04-27


## Changes

### Add supervisor to essentials and nfs-server

This release defines a new `supervisor` systemd service on the
essentials and nfs-server images. When enabled it will run `supervisord`
in the standard php container for the system. Logs are written to the
host at `/var/log/supervisor/supervisor.log`. Program configuration can
be provided either in a custom container at
`/etc/supervisor/conf.d/*.conf` or via the host
`/etc/supervisor/*.conf`. The configuration for supervisor itself is not
modifiable directly. A shim, `supervisorctl`, is provided on the host
that allows for controlling it as though it were installed on the host.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| RabbitMQ  | 4.2.5    | 4.3.0   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.23  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.23  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.23  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.20, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.23  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.5, composer-2.9.7      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.23  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.23    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.23    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.23    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.23    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.23        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.23        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.23        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.23        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.3.0                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.23           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.23            |
---
# 2026.22
URL: https://docs.webscale.com/docs/reference/images/2026.22/
Description: Released 2026-04-15


## Changes

### Add amd64 container-host image

For those cases where an arm64 container-host will not work, an amd64
`container-host` image is published starting with this release.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Alpine    | 3.21.6   | 3.21.7  |
| Alpine    | 3.23.3   | 3.23.4  |
| Composer  | 2.9.5    | 2.9.7   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.22  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.22  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.22  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.20, composer-2.9.7     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.22  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.5, composer-2.9.7      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.22  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.22    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.22    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.22    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.22    |
| Container  | php-fpm:8.1       | Alpine 3.21.7        | 8.1.34, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.22        |
| Container  | php-fpm:8.2       | Alpine 3.23.4        | 8.2.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.22        |
| Container  | php-fpm:8.3       | Alpine 3.23.4        | 8.3.30, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.22        |
| Container  | php-fpm:8.4       | Alpine 3.23.4        | 8.4.20, composer-2.9.7     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.22        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.22           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.22            |
---
# 2026.21
URL: https://docs.webscale.com/docs/reference/images/2026.21/
Description: Released 2026-04-13


## Changes

### NFS server commands for managing packages

With the creation of the `webscale-redis` and `webscale-opensearch`
packages comes the need to be able to install them on newer base images
where root access is not provided. To enable this, this release contains
commands `install-package` and `uninstall-package` that take a package
name (`redis` or `opensearch`) and automatically handle the privilege
escalation to install or uninstall the packages.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| PHP       | 8.4.19   | 8.4.20  |
| PHP       | 8.5.4    | 8.5.5   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.21  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.21  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.21  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.20, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.21  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.5, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.21  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.21    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.21    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.21    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.20, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.21    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.21        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.21        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.21        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.20, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.21        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.21           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.21            |
---
# 2026.20
URL: https://docs.webscale.com/docs/reference/images/2026.20/
Description: Released 2026-04-09


## Changes

### New webscale-opensearch package

This release begins publishing a new `webscale-opensearch` debian package that
is used on V4 and older hosting environments to install an NFS-server-local
OpenSearch or Elasticsearch service.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.20  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.20  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.20  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.19, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.20  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.4, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.20  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.20    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.20    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.20    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.20    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.20        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.20        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.20        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.20        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.20           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.20            |
---
# 2026.19
URL: https://docs.webscale.com/docs/reference/images/2026.19/
Description: Released 2026-03-30


## Changes

### Improvements to webscale-redis

This release makes multiple improvements to the `webscale-redis` package.

* The default version is now 6.2.6 to match current usage.
* Ownership of `/etc/redis/*` and `/var/log/redis/*` has been fixed so that
  the `adm` group members can update configuration and view logs.
* Control of the `redis-volatile` and `redis-persistent` systemd
  services can now be done by members of the `adm` group.
* `/etc/redis/env` is added as a conf file so it will be retained on
  future upgrades.
* The previous network bind was for loopback only. This change updates
  it to listen on all interfaces.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.19  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.19  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.19  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.19, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.19  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.4, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.19  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.19    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.19    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.19    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.19    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.19        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.19        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.19        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.19        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.19           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.19            |
---
# 2026.18
URL: https://docs.webscale.com/docs/reference/images/2026.18/
Description: Released 2026-03-26


## Changes

### New webscale-redis package

This release begins publishing a new `webscale-redis` debian package that is
used on V4 and before hosting environments to install NFS-server-local
volatile and persistent Redis services.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.18  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.18  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.18  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.19, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.18  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.4, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.18  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.18    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.18    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.18    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.18    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.18        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.18        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.18        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.18        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.18           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.18            |
---
# 2026.17
URL: https://docs.webscale.com/docs/reference/images/2026.17/
Description: Released 2026-03-26


## Changes

### Fix: docker compose fails with $ in secret

When a `$` character was included in a secret, invoker would naively write it to
a docker compose `.env` file. However, docker compose interpolates variables
using the `$` character resulting in unwanted behavior. This change first
updates the web server image to remove the relatively ancient `docker-compose`
command; `docker compose` must now be used instead. Invoker is updated to use
the new command and properly encodes values in the `.env` file using single
quotes and proper escaping, correcting the reported problem.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Debian    | 13.3     | 13.4    |
| RabbitMQ  | 4.2.4    | 4.2.5   |
| Varnish   | 6.0.16   | 6.0.17  |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.17  |
| Container  | php-fpm:8.2-arm64 | Debian 13.4          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.17  |
| Container  | php-fpm:8.3-arm64 | Debian 13.4          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.17  |
| Container  | php-fpm:8.4-arm64 | Debian 13.4          | 8.4.19, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.17  |
| Container  | php-fpm:8.5-arm64 | Debian 13.4          | 8.5.4, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.17  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.17    |
| Container  | php-fpm:8.2-deb   | Debian 13.4          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.17    |
| Container  | php-fpm:8.3-deb   | Debian 13.4          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.17    |
| Container  | php-fpm:8.4-deb   | Debian 13.4          | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.17    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.17        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.17        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.17        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.17        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.5                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.17           |
| Container  | varnish           | Debian 12.13         | 6.0.17                     | arm64 | public.ecr.aws/webscale/varnish:2026.17            |
---
# 2026.16
URL: https://docs.webscale.com/docs/reference/images/2026.16/
Description: Released 2026-03-13


## Changes

This release contains Webscale-internal changes and component upgrades.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| PHP       | 8.4.18   | 8.4.19  |
| PHP       | 8.5.3    | 8.5.4   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.16  |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.16  |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.16  |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.19, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.16  |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.4, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.16  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.16    |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.16    |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.16    |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.16    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.16        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.16        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.16        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.19, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.16        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.16           |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.16            |
---
# 2026.15
URL: https://docs.webscale.com/docs/reference/images/2026.15/
Description: Released 2026-02-26


## Changes

### Minor Debian container image updates

For Debian-based php-fpm container images, the `jq`, `npm`, `openssh-client`,
`rsync`, and `supervisor` packages are now included.

### Bug fix for auxiliary clusters

When multiple auxiliary clusters were configured in `/var/www/deploy/conf.yml`
and an earlier one was running no servers, later clusters would not be processed
as expected. This change causes processing to continue in almost every case.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.15  |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.15  |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.15  |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.18, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.15  |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.3, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.15  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.15    |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.15    |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.15    |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.15    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.15        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.15        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.15        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.15        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.15           |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.15            |
---
# 2026.13
URL: https://docs.webscale.com/docs/reference/images/2026.13/
Description: Released 2026-02-19


## Changes

### Minor Debian container image updates

- PHP-FPM container images now include full vim instead of vim-tiny.
- Containers are given a more user-friendly bash prompt.
- Some temporary installation files used during PHP-FPM container builds
  are removed.

### Minor VM image updates

- The command `configure-environment` is made specific to the web server
  VM images builds only, since that is where it is useful.
- The `clinvoker`  which is included in every web server VM image will
  now process cluster metadata.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.13  |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.13  |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.13  |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.18, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.13  |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.3, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.13  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.13    |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.13    |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.13    |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.13    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.13        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.13        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.13        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.13        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.13           |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.13            |
---
# 2026.11
URL: https://docs.webscale.com/docs/reference/images/2026.11/
Description: Released 2026-02-18


## Changes

Only Webscale-internal changes are included in this release.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| RabbitMQ  | 4.2.3    | 4.2.4   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.11  |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.11  |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.11  |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.18, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.11  |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.3, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.11  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.11    |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.11    |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.11    |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.11    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.11        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.11        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.11        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.11        |
| Container  | rabbitmq          | Ubuntu 24.04.4 LTS   | 4.2.4                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.11           |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.11            |
---
# 2026.10
URL: https://docs.webscale.com/docs/reference/images/2026.10/
Description: Released 2026-02-17


## Changes

### Fix egress-proxy not applied in containerized environments

Previously, when code requiring an egress-proxy was
run as a container, the configuration given in `PROXY_HOSTNAMES` and
`PROXY_ADDRESS` were ineffective. This release fixes the issue by adding
additional directives to container creation so that named hosts will be directed
at a specified proxy address from within a container environment.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| PHP       | 8.4.17   | 8.4.18  |
| PHP       | 8.5.2    | 8.5.3   |


## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.10  |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.10  |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.10  |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.18, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.10  |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.3, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.10  |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.10    |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.10    |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.10    |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.10    |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.10        |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.10        |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.10        |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.18, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.10        |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | 4.2.3                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.10           |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.10            |
---
# 2026.9
URL: https://docs.webscale.com/docs/reference/images/2026.9/
Description: Released 2026-02-12


## Changes

### Fix egress-proxy mistakenly returns 421

In previous release [2026.6](/docs/reference/images/2026.6/), if an origin certificate was generated
with uppercase characters, the egress proxy could fail to match the request
hostname. This resulted in either a 421 Misdirected Request response or an
unrecognized_name (112) TLS alert. The issue was caused by a case-sensitive
hostname comparison when validating configured hosts. Since DNS hostnames are
case-insensitive, this behavior was incorrect.

This release fixes the issue by performing hostname comparisons in a
case-insensitive manner, ensuring correct request routing regardless of
character casing in the origin certificate.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.9   |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.9   |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.9   |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.17, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.9   |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.2, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.9   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.9     |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.9     |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.9     |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.17, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.9     |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.9         |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.9         |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.9         |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.17, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.9         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | 4.2.3                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.9            |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.9             |
---
# 2026.8
URL: https://docs.webscale.com/docs/reference/images/2026.8/
Description: Released 2026-02-04


## Changes

There are two changes for PHP container images.

### Bad configuration support

Release [2026.7](/docs/reference/images/2026.7/) described a problem caused by upstream changes
exposing bad configuration files. This release contains a workaround that
allows bad configurations to continue to be used. A new configuration file
`x-webscale.conf` adds an explicit `listen = 9000` and is processed after
`www.conf`. This effectively reverts the upstream change and avoids immediate
problems for consumers of the latest image.

### Fixed msmtp path

When Debian images (amd64 and arm64) were first introduced in
`2025.30`, the `sendmail_path` PHP configuration directive
inadvertently referred to the wrong path for the `msmtp` program, causing mail
to fail to send. The path is now correct.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Composer  | 2.9.4    | 2.9.5   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.8   |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.8   |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.8   |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.17, composer-2.9.5     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.8   |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.2, composer-2.9.5      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.8   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.8     |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.8     |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.8     |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.17, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.8     |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.8         |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.8         |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.8         |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.17, composer-2.9.5     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.8         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | 4.2.3                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.8            |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.8             |
---
# 2026.7
URL: https://docs.webscale.com/docs/reference/images/2026.7/
Description: Released 2026-01-28


## Changes

### PHP 8.3 and PHP 8.4 compatibility

This release resolves the issue that led to the withdrawal of PHP 8.3 and PHP
8.4 container images at version 2026.6.

#### Background

Upstream packaging changes moved the `listen = 9000` override from
`zz-docker.conf` to `docker.conf`. Because `docker.conf` is loaded before the
default `www.conf`, the legacy setting `listen = 127.0.0.1:9000` in `www.conf`
took precedence, making PHP-FPM inaccessible from outside the container. This
release corrects the default `www.conf` provided in Webscale-built images.

#### Important note for custom images

Building custom images derived from these base images without replacing
`www.conf` will work without issue. However, if your build replaces `www.conf`
and includes `listen = 127.0.0.1:9000`, you must remove that line for the
container to function correctly.

* **Recommendation**: We strongly recommend avoiding the replacement of the entire
`www.conf file`. Instead, use `z-overrides.conf` (or similar) to include only
the specific settings that differ from the default. This ensures your image
automatically inherits future upstream fixes.

### Improved logging

The log format specification in the `www.conf` supplied with PHP container
images has been corrected.

* **Fix:** Resolved quoting issues in the Dockerfile that caused logs to contain
  extra backslashes and missing quotes around the constructed HTTP request.

* **New Feature:** Added the `Webscale-Request-Id` header to the logs. This
  facilitates easy correlation of PHP-FPM access logs with Traffic Viewer.

### Composer changes

* **Composer 1 Removal:** PHP 8.3 and PHP 8.4 container images no longer include
Composer version 1.

* **Default Version:** The command `/usr/local/bin/composer` now invokes Composer
version 2.

* **Backward Compatibility:** The command `composer2` remains supported as an
alias.

### PHP 8.5

A new arm64-based container image is released for PHP 8.5.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Alpine    | 3.23.2   | 3.23.3  |
| Composer  | 2.9.3    | 2.9.4   |
| PHP       | 8.3.29   | 8.3.30  |
| PHP       | 8.4.16   | 8.4.17  |
| rabbitmq  | 4.2.2    | 4.2.3   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | 8.1.34, composer-2.9.4     | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.7   |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | 8.2.30, composer-2.9.4     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.7   |
| Container  | php-fpm:8.3-arm64 | Debian 13.3          | 8.3.30, composer-2.9.4     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.7   |
| Container  | php-fpm:8.4-arm64 | Debian 13.3          | 8.4.17, composer-2.9.4     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.7   |
| Container  | php-fpm:8.5-arm64 | Debian 13.3          | 8.5.2, composer-2.9.4      | arm64 | public.ecr.aws/webscale/php-fpm:8.5-arm64-2026.7   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | 8.1.34, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.7     |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | 8.2.30, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.7     |
| Container  | php-fpm:8.3-deb   | Debian 13.3          | 8.3.30, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.7     |
| Container  | php-fpm:8.4-deb   | Debian 13.3          | 8.4.17, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.7     |
| Container  | php-fpm:8.1       | Alpine 3.21.6        | 8.1.34, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.7         |
| Container  | php-fpm:8.2       | Alpine 3.23.3        | 8.2.30, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.7         |
| Container  | php-fpm:8.3       | Alpine 3.23.3        | 8.3.30, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.7         |
| Container  | php-fpm:8.4       | Alpine 3.23.3        | 8.4.17, composer-2.9.4     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.7         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | 4.2.3                      | arm64 | public.ecr.aws/webscale/rabbitmq:2026.7            |
| Container  | varnish           | Debian 12.13         | 6.0.16                     | arm64 | public.ecr.aws/webscale/varnish:2026.7             |
---
# 2026.6
URL: https://docs.webscale.com/docs/reference/images/2026.6/
Description: Released 2026-01-21


## Changes

### New egress-proxy

An egress proxy is an optional component within a hosting environment
designed to route outbound HTTP and HTTPS traffic through a fixed,
static IP address. Structurally, this proxy is deployed on the NFS
server and is configured for specific hostnames via the web server
cluster metadata settings.

See [the docs](/docs/how-tos/egress-proxy/) for more detail.

**NOTE** Container images for PHP 8.3 and PHP 8.4 are not part of this release
because of apparent upstream problems.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | php 8.1.34, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.6   |
| Container  | php-fpm:8.2-arm64 | Debian 13.3          | php 8.2.30, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.6   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.6     |
| Container  | php-fpm:8.2-deb   | Debian 13.3          | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.6     |
| Container  | php-fpm:8.1       | Alpine 3.21.5        | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.6         |
| Container  | php-fpm:8.2       | Alpine 3.23.2        | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.6         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | rabbitmq 4.2.2             | arm64 | public.ecr.aws/webscale/rabbitmq                   |
| Container  | varnish           | Debian 12.13         | varnish-6.0.16             | arm64 | public.ecr.aws/webscale/varnish                    |
---
# 2026.5
URL: https://docs.webscale.com/docs/reference/images/2026.5/
Description: Released 2026-01-13


## Changes

This release makes two changes with respect to origin certificates for
applications using web-server images in a cluster:

1. The origin certificate authority is automatically trusted.
2. Server certificates for all applications are made available for use.

### Origin certificate authority

The origin certificate authority is used to sign origin certificates for
all applications within a control plane account. This CA is written to
`/usr/local/share/ca-certificates/webscale-account-ca.crt` and added to
the system's trusted certificate authorities by running
`update-ca-certificates`.

### Certificates for a single application

The server certificate for the application is written to the file
`/etc/nginx/snippets/webscale.pem`. To use it, the nginx site
configuration should contain `include snippets/webscale.conf` in a
server block with `listen 443 ssl;`. No other `ssl_*` parameters should
be configured. This enables all aliases configured for a cluster-using
application at the time the web server is created. If additional aliases
are added or removed, the cluster must be re-deployed to receive the
updated configuration. When utilizing this feature, the responsibility
for TLS configuration shfits to the base image instead of being
assigned to each environment.

#### Multiple applications

When multiple applications are assigned to a cluster server, multiple
server blocks must be used because nginx supports only a single server
certificate per server block. In this case each application should have
its own server block and use `include snippets/id.conf` where `id` is
the application id.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | php 8.1.34, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.3   |
| Container  | php-fpm:8.2-arm64 | Debian 13.2          | php 8.2.30, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.3   |
| Container  | php-fpm:8.3-arm64 | Debian 13.2          | php 8.3.29, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.3   |
| Container  | php-fpm:8.4-arm64 | Debian 13.2          | php 8.4.16, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.3   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.3     |
| Container  | php-fpm:8.2-deb   | Debian 13.2          | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.3     |
| Container  | php-fpm:8.3-deb   | Debian 13.2          | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.3     |
| Container  | php-fpm:8.4-deb   | Debian 13.2          | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.3     |
| Container  | php-fpm:8.1       | Alpine 3.21.5        | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.3         |
| Container  | php-fpm:8.2       | Alpine 3.23.2        | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.3         |
| Container  | php-fpm:8.3       | Alpine 3.23.2        | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.3         |
| Container  | php-fpm:8.4       | Alpine 3.23.2        | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.3         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | rabbitmq 4.2.2             | arm64 | public.ecr.aws/webscale/rabbitmq                   |
| Container  | varnish           | Debian 12.12         | varnish-6.0.16             | arm64 | public.ecr.aws/webscale/varnish                    |
---
# 2026.4
URL: https://docs.webscale.com/docs/reference/images/2026.4/
Description: Released 2026-01-08


## Changes

This release addresses a regression in the nfs-server image and
introduces significant enhancements to deployment orchestration and
environment management.

### Fix EE-1846 list-images fails

- deploy-cli: Restored the command to nfs-server VM images. It was
  previously omitted in releases 2026.2 and 2026.3. This had no impact
  on existing servers.

### Improvements to ComposeUp

- Project names are now inferred from compose.yaml (manual override
  still supported).
- Now runs natively within the project directory rather than using
  explicit --file flags.
- Added support for environment specification and AWS Secrets Manager to
  match ContainerRun logic.
- Generated environment variables are persisted to a local .env file for
  subsequent command use.

### Deployment with managed clusters

- run-deploy-and-cleanup: Now supports managed clusters via a `cluster`
  key in `/var/www/deploy/conf.yml`.
- Maintenance Mode: Add `enter_maintenance: true` to `conf.yml` to
  toggle maintenance mode during the deployment lifecycle when using
  managed clusters.
- Hook lifecycle for managed clusters:
    1. App enters maintenance mode (optional)
    2. "Started" hooks execute
    3. New deployment activates
    4. "Verified" hooks execute
    5. App exits maintenance mode (optional)
- Compatibility: When using managed clusters, `blue-green-deploy` is no
  longer supported and legacy `conf.yml` attributes are ignored.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | php 8.1.34, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.3   |
| Container  | php-fpm:8.2-arm64 | Debian 13.2          | php 8.2.30, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.3   |
| Container  | php-fpm:8.3-arm64 | Debian 13.2          | php 8.3.29, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.3   |
| Container  | php-fpm:8.4-arm64 | Debian 13.2          | php 8.4.16, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.3   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.3     |
| Container  | php-fpm:8.2-deb   | Debian 13.2          | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.3     |
| Container  | php-fpm:8.3-deb   | Debian 13.2          | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.3     |
| Container  | php-fpm:8.4-deb   | Debian 13.2          | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.3     |
| Container  | php-fpm:8.1       | Alpine 3.21.5        | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.3         |
| Container  | php-fpm:8.2       | Alpine 3.23.2        | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.3         |
| Container  | php-fpm:8.3       | Alpine 3.23.2        | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.3         |
| Container  | php-fpm:8.4       | Alpine 3.23.2        | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.3         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | rabbitmq 4.2.2             | arm64 | public.ecr.aws/webscale/rabbitmq                   |
| Container  | varnish           | Debian 12.12         | varnish-6.0.16             | arm64 | public.ecr.aws/webscale/varnish                    |
---
# 2026.3
URL: https://docs.webscale.com/docs/reference/images/2026.3/
Description: Released 2026-01-07


## Changes

- The `web-server` VM image is enhanced to use instance profile permissions
  with the `amazon-ecr-credential-helper` so that invoker will be able to
  automatically pull images without `PrepareEcrLoginPassword`. This is
  necessary for the new `ComposeUp` command, since it does not have a
  mechanism to pass credentials using a file reference, but can also be
  used with `ContainerRun` by omitting `username` and `password`
  parameters.

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | php 8.1.34, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.3   |
| Container  | php-fpm:8.2-arm64 | Debian 13.2          | php 8.2.30, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.3   |
| Container  | php-fpm:8.3-arm64 | Debian 13.2          | php 8.3.29, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.3   |
| Container  | php-fpm:8.4-arm64 | Debian 13.2          | php 8.4.16, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.3   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.3     |
| Container  | php-fpm:8.2-deb   | Debian 13.2          | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.3     |
| Container  | php-fpm:8.3-deb   | Debian 13.2          | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.3     |
| Container  | php-fpm:8.4-deb   | Debian 13.2          | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.3     |
| Container  | php-fpm:8.1       | Alpine 3.21.5        | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.3         |
| Container  | php-fpm:8.2       | Alpine 3.23.2        | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.3         |
| Container  | php-fpm:8.3       | Alpine 3.23.2        | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.3         |
| Container  | php-fpm:8.4       | Alpine 3.23.2        | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.3         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | rabbitmq 4.2.2             | arm64 | public.ecr.aws/webscale/rabbitmq                   |
| Container  | varnish           | Debian 12.12         | varnish-6.0.16             | arm64 | public.ecr.aws/webscale/varnish                    |
---
# 2026.2
URL: https://docs.webscale.com/docs/reference/images/2026.2/
Description: Released 2026-01-06


## Changes
- The debian-based php 8.1 build is now available for the arm64
  architecture.
- The `unzip` package is now installed on all debian-based php 8.1+
  container images, allowing Magento to install without requiring
  permissions changes.
- The `/var/www` directory is created in debian-based php 8.1+
  container images to allow it to be bind-mounted to a host directory.
- The file `/var/log/msmtp.log` is created with owner www-data and group
  www-data in debian-based php 8.1+ container images to allow msmtp
  logging to occur without changes to customer-specific builds.
- The web server VM image now includes docker compose support.
- A new invoker command `command.ComposeUp` allows running docker
  compose up as part of an invoker sequence.
- The package `vim-tiny` is used on new servers instead of the full
  `vim`.
- A new command on NFS servers, `label-shared-disk`, sets the `shared`
  label on an unassigned NVMe device, allowing a previous shared disk to
  be labeled on a new instance after its attachment in AWS.
- A new command on NFS servers, `unmount-shared-disk`, allows an
  existing shared disk to be unmounted so that it can be safely
  detached.
- A new command on NFS servers, `mount-shared-disk`, allows mounting a
  volume with the `shared` label.
- The unused invoker service has been removed from `nfs-server` and
  `generic-server` VM images.

## Component upgrades

| Component | Previous | Current |
|---        |---       |---      |
| Alpine    | 3.22.2   | 3.23.2  |
| Composer  | 2.9.1    | 2.9.3   |
| PHP       | 8.1.33   | 8.1.34  |
| PHP       | 8.2.29   | 8.2.30  |
| PHP       | 8.3.27   | 8.3.29  |
| PHP       | 8.4.14   | 8.4.16  |
| rabbitmq  | 4.2.1    | 4.2.2   |

## Artifacts matrix

| Image Type | Family / Variant  | OS                   | Packages                   | Architectures | URI |
|---         |---                |---                   |---                         |---            |---|
| VM         | nfs-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | web-server        | Ubuntu Minimal 24.04 |                            | amd64, arm64 | |
| VM         | container-host    | Ubuntu Minimal 24.04 |                            | arm64 | |
| Container  | php-fpm:8.1-arm64 | Debian 13.2          | php 8.1.34, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.1-arm64-2026.2   |
| Container  | php-fpm:8.2-arm64 | Debian 13.2          | php 8.2.30, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2026.2   |
| Container  | php-fpm:8.3-arm64 | Debian 13.2          | php 8.3.29, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2026.2   |
| Container  | php-fpm:8.4-arm64 | Debian 13.2          | php 8.4.16, composer-2.9.3 | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2026.2   |
| Container  | php-fpm:8.1-deb   | Debian 13.2          | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2026.2     |
| Container  | php-fpm:8.2-deb   | Debian 13.2          | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2026.2     |
| Container  | php-fpm:8.3-deb   | Debian 13.2          | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2026.2     |
| Container  | php-fpm:8.4-deb   | Debian 13.2          | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2026.2     |
| Container  | php-fpm:8.1       | Alpine 3.21.5        | php 8.1.34, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2026.2         |
| Container  | php-fpm:8.2       | Alpine 3.23.2        | php 8.2.30, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2026.2         |
| Container  | php-fpm:8.3       | Alpine 3.23.2        | php 8.3.29, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2026.2         |
| Container  | php-fpm:8.4       | Alpine 3.23.2        | php 8.4.16, composer-2.9.3 | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2026.2         |
| Container  | rabbitmq          | Ubuntu 24.04.3 LTS   | rabbitmq 4.2.2             | arm64 | public.ecr.aws/webscale/rabbitmq                   |
| Container  | varnish           | Debian 12.12         | varnish-6.0.16             | arm64 | public.ecr.aws/webscale/varnish                    |
---
# 2025.44
URL: https://docs.webscale.com/docs/reference/images/2025.44/
Description: Released 2025-11-19


## Changes
- Add [container shutdown hooks](/docs/reference/shutdown-hooks/)
- Install libzip on Debian container images. In versions 2025.33 through 2025.41, the zip extension was non-functional on Debian-13-based images
- Container images based on Debian 13 have been upgraded from 13.1 to 13.2
- PHP 8.4 container images are updated to php 8.4.14 from 8.4.13
- PHP 8.3 container images are updated to php 8.3.27 from 8.3.26

## Artifacts matrix

| Image Type | Family / Variant             | OS                   | Packages      | Architectures | URI |
|---         |---                           |---                   |---            |---            |---|
| VM         | nfs-server                   | Ubuntu Minimal 24.04 |                | amd64, arm64 | |
| VM         | web-server                   | Ubuntu Minimal 24.04 |                | amd64, arm64 | |
| VM         | container-host               | Ubuntu Minimal 24.04 |                | arm64 | |
| Container  | php-fpm:8.2-arm64            | Debian 13.2          | php 8.2.29     | arm64 | public.ecr.aws/webscale/php-fpm:8.2-arm64-2025.44 |
| Container  | php-fpm:8.3-arm64            | Debian 13.2          | php 8.3.27     | arm64 | public.ecr.aws/webscale/php-fpm:8.3-arm64-2025.44 |
| Container  | php-fpm:8.4-arm64            | Debian 13.2          | php 8.4.14     | arm64 | public.ecr.aws/webscale/php-fpm:8.4-arm64-2025.44 |
| Container  | php-fpm:8.1-deb              | Debian 13.2          | php 8.1.33     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-deb-2025.44 |
| Container  | php-fpm:8.2-deb              | Debian 13.2          | php 8.2.29     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-deb-2025.44 |
| Container  | php-fpm:8.3-deb              | Debian 13.2          | php 8.3.27     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-deb-2025.44 |
| Container  | php-fpm:8.4-deb              | Debian 13.2          | php 8.4.14     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-deb-2025.44 |
| Container  | php-fpm:8.1                  | Alpine 3.21.5        | php 8.1.33     | amd64 | public.ecr.aws/webscale/php-fpm:8.1-2025.44 |
| Container  | php-fpm:8.2                  | Alpine 3.22.2        | php 8.2.29     | amd64 | public.ecr.aws/webscale/php-fpm:8.2-2025.44 |
| Container  | php-fpm:8.3                  | Alpine 3.22.2        | php 8.3.27     | amd64 | public.ecr.aws/webscale/php-fpm:8.3-2025.44 |
| Container  | php-fpm:8.4                  | Alpine 3.22.2        | php 8.4.14     | amd64 | public.ecr.aws/webscale/php-fpm:8.4-2025.44 |
| Container  | rabbitmq                     | Ubuntu 24.04.3 LTS   | rabbitmq 4.2.1 | arm64 | public.ecr.aws/webscale/rabbitmq |
| Container  | varnish                      | Debian 12.12         | varnish-6.0.16 | arm64 | public.ecr.aws/webscale/varnish |
---
# 2025.41
URL: https://docs.webscale.com/docs/reference/images/2025.41/
Description: Released 2025-10-23


**Highlights**
- Add rabbitmq-delayed-message-exchange plugin
- Alpine 3.21.4 has been updated to 3.21.5
- Alpine 3.22.1 has been updated to 3.22.2

## Artifacts matrix

| Image Type | Family / Variant             | Base / Details            | Architectures |
|---         |---                           |---                        |---|
| VM         | `nfs-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `web-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `container-host`             | Ubuntu Minimal 24.04      | arm64 |
| Container  | `php-fpm` 8.1 (debian)       | Debian 13 “Trixie”        | amd64 |
| Container  | `php-fpm` 8.2 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.3 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.4 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.1 (alpine)       | Alpine 3.21.5, php 8.1.33 | amd64 |
| Container  | `php-fpm` 8.2 (alpine)       | Alpine 3.22.2, php 8.2.29 | amd64 |
| Container  | `php-fpm` 8.3 (alpine)       | Alpine 3.22.2, php 8.3.26 | amd64 |
| Container  | `php-fpm` 8.4 (alpine)       | Alpine 3.22.2, php 8.4.13 | amd64 |
| Container  | `rabbitmq` 4.1.4             | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `varnish` (entrypoint)       | Varnish Cache 6.0.16      | arm64 |

## Changes
- Add rabbitmq-delayed-message-exchange plugin
- Began republishing latest rabbitmq with `rabbitmq-delayed-message-exchange` plugin installed (but not enabled).
- Removed `set-rabbitmq-version` command as it is no longer used.
---
# 2025.38
URL: https://docs.webscale.com/docs/reference/images/2025.38/
Description: Released 2025-10-02


**Highlights**
- Corrected Varnish memory leak.
- The PHP 8.3 version is updated to PHP 8.3.26
- The PHP 8.4 version is updated to PHP 8.4.13

## Artifacts matrix

| Image Type | Family / Variant             | Base / Details            | Architectures |
|---         |---                           |---                        |---|
| VM         | `nfs-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `web-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `container-host`             | Ubuntu Minimal 24.04      | arm64 |
| Container  | `php-fpm` 8.1 (debian)       | Debian 13 “Trixie”        | amd64 |
| Container  | `php-fpm` 8.2 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.3 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.4 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.1 (alpine)       | Alpine 3.21.4, php 8.1.33 | amd64 |
| Container  | `php-fpm` 8.2 (alpine)       | Alpine 3.22.1, php 8.2.29 | amd64 |
| Container  | `php-fpm` 8.3 (alpine)       | Alpine 3.22.1, php 8.3.26 | amd64 |
| Container  | `php-fpm` 8.4 (alpine)       | Alpine 3.22.1, php 8.4.13 | amd64 |
| Container  | `varnish` (entrypoint)       | Varnish Cache 6.0.16      | arm64 |

## Changes
- Downgraded the Varnish Cache version to the stable version, fixing a memory leak.
- Instance upgrade scripts are corrected
---
# 2025.36
URL: https://docs.webscale.com/docs/reference/images/2025.36/
Description: Released 2025-09-20


**Highlights**
- Fixed issue causing long headers to fail in the varnish cache

## Artifacts matrix

| Image Type | Family / Variant             | Base / Details            | Architectures |
|---         |---                           |---                        |---|
| VM         | `nfs-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `web-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `container-host`             | Ubuntu Minimal 24.04      | arm64 |
| Container  | `php-fpm` 8.1 (debian)       | Debian 13 “Trixie”        | amd64 |
| Container  | `php-fpm` 8.2 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.3 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.4 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.1 (alpine)       | Alpine 3.21.4, php 8.1.33 | amd64 |
| Container  | `php-fpm` 8.2 (alpine)       | Alpine 3.22.1, php 8.2.29 | amd64 |
| Container  | `php-fpm` 8.3 (alpine)       | Alpine 3.22.1, php 8.3.25 | amd64 |
| Container  | `php-fpm` 8.4 (alpine)       | Alpine 3.22.1, php 8.4.12 | amd64 |
| Container  | `varnish` (entrypoint)       | Varnish Cache 7.6.5       | arm64 |

## Changes
- Fixed issue causing long headers to fail in the varnish cache
---
# 2025.34
URL: https://docs.webscale.com/docs/reference/images/2025.34/
Description: Released 2025-09-19


**Highlights**
- Added an arm64 container image for php 8.2.

## Artifacts matrix

| Image Type | Family / Variant            | Base / Details             | Architectures |
|---         |---                           |---                        |---|
| VM         | `nfs-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `web-server`                 | Ubuntu Minimal 24.04      | amd64, arm64 |
| VM         | `container-host`             | Ubuntu Minimal 24.04      | arm64 |
| Container  | `php-fpm` 8.1 (debian)       | Debian 13 “Trixie”        | amd64 |
| Container  | `php-fpm` 8.2 (debian)       | Debian 13 “Trixie”        | amd64, **arm64** |
| Container  | `php-fpm` 8.3 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.4 (debian)       | Debian 13 “Trixie”        | amd64, arm64 |
| Container  | `php-fpm` 8.1 (alpine)       | Alpine 3.21.4, php 8.1.33 | amd64 |
| Container  | `php-fpm` 8.2 (alpine)       | Alpine 3.22.1, php 8.2.29 | amd64 |
| Container  | `php-fpm` 8.3 (alpine)       | Alpine 3.22.1, php 8.3.25 | amd64 |
| Container  | `php-fpm` 8.4 (alpine)       | Alpine 3.22.1, php 8.4.12 | amd64 |
| Container  | `varnish` (entrypoint)       | Varnish 7.6.5             | arm64 |

## Changes
- Added an arm64 container image for php 8.2.
---
# 2025.33
URL: https://docs.webscale.com/docs/reference/images/2025.33/
Description: Released 2025-09-18


**Highlights**
- Debian variants move to **Debian 13.1 “Trixie”**.
- Alpine variants updated to **3.21.4 / 3.22.1** as applicable.
- `varnish` container now auto-allocates **~80%** of host RAM for caching.

## Artifacts matrix

| Image Type | Family / Variant            | Base / Details          | Architectures |
|---         |---                           |---                       |---|
| VM         | `nfs-server`                 | `rabbitmq` service available               | amd64, arm64 |
| VM         | `web-server`                 | `libnginx-mod-http-image-filter` available | amd64, arm64 |
| VM         | `container-host`             | —                        | **arm64 only** |
| Container  | `php-fpm` 8.1 (debian)       | Debian 13 “Trixie”      | amd64 |
| Container  | `php-fpm` 8.2 (debian)       | Debian 13 “Trixie”      | amd64 |
| Container  | `php-fpm` 8.3 (debian)       | Debian 13 “Trixie”      | amd64, **arm64** |
| Container  | `php-fpm` 8.4 (debian)       | Debian 13 “Trixie”      | amd64, **arm64** |
| Container  | `php-fpm` 8.1 (alpine)       | Alpine 3.21.4           | amd64 |
| Container  | `php-fpm` 8.2 (alpine)       | Alpine 3.22.1           | amd64 |
| Container  | `php-fpm` 8.3 (alpine)       | Alpine 3.22.1           | amd64 |
| Container  | `php-fpm` 8.4 (alpine)       | Alpine 3.22.1           | amd64 |
| Container  | `varnish` (entrypoint)       | Memory ~80% of host     | **arm64 only** |

## Changes

### [vm:nfs-server] rabbitmq service
- Removed unused `rabbitmq-server` package; added containerized `rabbitmq`.
- Config: `/etc/rabbitmq/rabbitmq.conf`; data: `/var/lib/rabbitmq`.
- `adm` users may edit config; default version **3.13**.
- Manage with `/opt/webscale/sbin/set-rabbitmq-version 3.13` or systemd:
  - `sudo systemctl enable|disable|restart|start|stop rabbitmq`
- Reset tool: `/opt/webscale/sbin/reset-rabbitmq` (cleans data, restarts).

### [vm:nfs-server] WMA configurability
- `adm` users can edit `/etc/webscale/wma-config.json` and restart `webscale-monitoring-agent` for log capture.

### [vm:web-server] libnginx-mod-http-image-filter
- Module installed and available for configuration.

### [vm:web-server] host networking mode
- `ContainerRun` invoker supports `network_mode: host`.

### [container:php-fpm:8.1-deb]
- PHP **8.1.33**; base **Debian 13 “Trixie”**.

### [container:php-fpm:8.2-deb]
- PHP **8.2.29**; base **Debian 13 “Trixie”**.

### [container:php-fpm:8.3-deb]
- PHP **8.3.25**; base **Debian 13 “Trixie”**.

### [container:php-fpm:8.3-arm64]
- PHP **8.3.25**; base **Debian 13 “Trixie”**.

### [container:php-fpm:8.4-deb]
- PHP **8.4.12**; base **Debian 13 “Trixie”**.

### [container:php-fpm:8.4-arm64]
- PHP **8.4.12**; base **Debian 13 “Trixie”**.

### [container:php-fpm:8.1 (alpine)]
- PHP **8.1.33**; base **Alpine 3.21.4**.

### [container:php-fpm:8.2 (alpine)]
- PHP **8.2.29**; base **Alpine 3.22.1**.

### [container:php-fpm:8.3 (alpine)]
- PHP **8.3.25**; base **Alpine 3.22.1**.

### [container:php-fpm:8.4 (alpine)]
- PHP **8.4.12**; base **Alpine 3.22.1**.

### [container:varnish]
- Entrypoint now sizes cache to **~80% of host memory**.
---
# ASN is
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/asn-is/
Description: Matches when the request originates from one or more Autonomous System Numbers included in the Defined ASNs list.


This condition determines if a request originated from a specific Autonomous System Number (ASN) by performing a geolocation lookup on the requester's IP address.

{{% alert title="Note:" %}}
This web control condition is available on both Request and Response web controls.
{{% /alert %}}

## Configuration

* **Defined ASNs:** A list of one or more ASNs to match against, each a positive number with no leading zero. The condition returns true if the request's ASN is present in this list. At least one ASN must be defined.

## Measurement

To evaluate this condition, the proxy resolves the IP address from the incoming request and matches it against a geolocation database. It retrieves the ASN associated with that IP and returns true if the number exists within the **Defined ASNs** list. If the IP address cannot be mapped to an ASN, the condition returns false.
---
# ASN is not
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/asn-is-not/
Description: Matches when the request originates from an Autonomous System Number not included in the Defined ASNs list.


This condition determines if a request originated from an Autonomous System Number (ASN) that is not present in a specified list.

{{% alert title="Note:" %}}
This web control condition is available on both Request and Response web controls.
{{% /alert %}}

## Configuration

* **Defined ASNs:** A list of one or more ASNs to exclude from matching, each a positive number with no leading zero. The condition returns true if the request's ASN is not present in this list. At least one ASN must be defined.

## Measurement

To evaluate this condition, the proxy resolves the IP address from the incoming request and performs a lookup against a geolocation database. It retrieves the ASN for the IP and returns true only if that number is absent from the **Defined ASNs** list. If the IP address cannot be mapped to an ASN, the condition returns true.
---
# Conditions
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/
Description: Conditions are logical criteria used to determine if one or more actions are applied to an incoming request or response.

---
# Cookie is set
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/cookie-is-set/
Description: Matches when a cookie with the exact specified name is present in the request.


This condition inspects the `Cookie` request header to verify the existence of a specific cookie name. It returns true if the named cookie is present in the incoming request.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the name comparison. When disabled, the condition performs a case-insensitive match against all cookies sent in the request.
* **Name**: The exact name the condition must match to return true. This field is required and supports a maximum of 50 characters.

## Measurement

The condition parses the `Cookie` header from the incoming request and evaluates the presence of the specified key.

* **Cookie present**: If a cookie key matching the configured **Name** is identified, the condition returns true.
* **Cookie absent**: If the specific cookie name is not found, the condition returns false.
* **Missing header**: If the `Cookie` header is absent from the request, the condition returns false.
---
# Cookie is not set
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/cookie-is-not-set/
Description: Matches when a cookie with the exact specified name is absent from the request.


This condition inspects the `Cookie` request header to verify the absence of a specific cookie name. It returns true if the named cookie is missing from the incoming request.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the name comparison. When disabled, the condition performs a case-insensitive match against all cookies sent in the request.
* **Name**: The exact name the condition must not match to return true. This field is required and supports a maximum of 50 characters.

## Measurement

The condition parses the `Cookie` header from the incoming request and evaluates the presence of the specified key.

* **Cookie present**: If a cookie key matching the configured **Name** is identified, the condition returns false.
* **Cookie absent**: If the specific cookie name is not found, the condition returns true.
* **Missing header**: If the `Cookie` header is absent from the request, the condition returns true.
---
# Cookie value matches
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/cookie-value-matches/
Description: Matches when a specific request cookie's value matches a regular expression pattern.


This condition inspects the `Cookie` request header to determine if the value of a specific cookie matches a [regular expression](https://www.regular-expressions.info/). It returns true if the named cookie contains a value that matches the defined pattern.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the name and value comparison. When disabled, the condition performs a case-insensitive match for the cookie name and evaluates the pattern against all cookies that match that name.
* **Cookie name**: The exact name of the cookie to inspect. This field is required and supports a maximum of 50 characters.
* **Cookie value pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the cookie's value. The condition returns true if the pattern matches the value of the specified cookie. This field is required and supports a maximum of 255 characters.

## Measurement

The condition extracts the specified cookie name from the `Cookie` request header and evaluates its value against the configured pattern.

* **Match found**: If the cookie's value matches the regular expression, the condition returns true.
* **No match found**: If the cookie's value does not match the pattern, the condition returns false.
* **Missing cookie**: If the specified cookie is absent from the request, the condition returns false.
---
# Cookie value does not match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/cookie-value-does-not-match/
Description: Matches when a specific request cookie's value does not match a regular expression pattern.


This condition inspects the `Cookie` request header to determine if the value of a specific cookie does not match a [regular expression](https://www.regular-expressions.info/). It returns true if the named cookie contains no values that match the defined pattern.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the name and value comparison. When disabled, the condition performs a case-insensitive match for the cookie name and evaluates the pattern against all cookies that match that name.
* **Cookie name**: The exact name of the cookie to inspect. This field is required and supports a maximum of 50 characters.
* **Cookie value pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the cookie's value. The condition returns true if the pattern does not match the value of the specified cookie. This field is required and supports a maximum of 255 characters.

## Measurement

The condition extracts the specified cookie name from the `Cookie` request header and evaluates its value against the configured pattern.

* **Match found**: If the cookie's value matches the regular expression, the condition returns false.
* **No match found**: If the cookie's value does not match the pattern, the condition returns true.
* **Missing cookie**: If the specified cookie is absent from the request, the condition returns true.
---
# Country of origin is
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/country-of-origin-is/
Description: Matches when the request originates from one or more countries included in the Selected countries list.


This condition determines if a request originated from a specific country by performing a geolocation lookup on the requester's IP address.

## Configuration

* **Selected countries**: A list of one or more countries to match against. The condition returns true if the request originates from any country in this list. At least one country must be selected.

## Measurement

The condition resolves the IP address from the incoming request and matches it against a geolocation database (MaxMind GeoLite2). It retrieves the ISO country code associated with that IP and returns true if the code exists within the **Selected countries** list. If the IP address cannot be mapped to a country, the condition returns false.
---
# Country of origin is not
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/country-of-origin-is-not/
Description: Matches when the request originates from a country not included in the Selected countries list.


This condition determines if a request originated from a country that is not present in a specified list.

## Configuration

* **Selected countries**: A list of one or more countries to exclude from matching. The condition returns true if the request originates from any country that is not in this list. At least one country must be selected.

## Measurement

The condition resolves the IP address from the incoming request and performs a lookup against a geolocation database (MaxMind GeoLite2). It retrieves the ISO country code for the IP and returns true only if that code is absent from the **Selected countries** list. If the IP address cannot be mapped to a country, the condition returns true.
---
# IP address in set
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/ip-address-in-set/
Description: Matches when the requester's IP address is present within a specified address set.


This condition identifies if the requester's IP address is in a pre-defined address set.

## Configuration

* **Select address set**: The named collection of IP addresses or CIDR ranges to match against. The condition returns true only if the requester's IP is found within this set. This field is required.

## Measurement

The condition resolves the IP address from the incoming request and evaluates it against the specified address set. The process validates the request IP against both individual addresses and CIDR notations. If the IP falls within the defined range, the condition returns true.
---
# IP address not in set
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/ip-address-not-in-set/
Description: Matches when the requester's IP address is absent from a specified address set.


This condition identifies if the requester's IP address is not in a pre-defined address set.

## Configuration

* **Select address set**: The named collection of IP addresses or CIDR ranges to check against. The condition returns true only if the requester's IP is not found within this set. This field is required.

## Measurement

The condition resolves the IP address from the incoming request and evaluates it against the specified address set. The process validates the request IP against both individual addresses and CIDR notations. If the IP falls outside the defined range, the condition returns true.
---
# IP address is allowlisted
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/ip-address-is-allowlisted/
Description: Matches when the requester's IP address is present in the allowlist.


This condition checks if the requester's IP address is included in the Allowlist within an account's address set. It compares the address from the request to the list of addresses managed in that section of the dashboard and returns true if a match is found.

## Configuration

No further configurations are necessary for this condition. The logic is applied automatically to all addresses currently present in the Allowlist.
---
# Create an environment
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/how-tos/create-an-environment/
Description: How to create an environment with the Webscale API.



An environment is a named group of [stacks](/hosting-platforms/hosting-v4/stacks/) and [clusters](/docs/how-tos/general/clusters/), such as production or staging. Every stack belongs to one.

Post the name of the environment:

```
curl -X POST "https://api.webscale.com/v2/environments" \
  -H "Authorization: Bearer <my-access-key>" \
  -H "Content-Type: application/json" \
  -d '{"name": "Production"}'
```

```
{
  "href": "/v2/environments/3ps666yxcanq",
  "name": "Production",
  "keyword": "production"
}
```

A stack takes that whole `href` in its `environment` field. See [Create an EKS stack](/hosting-platforms/hosting-v4/how-tos/create-an-eks-stack/) for an example.

Webscale builds the `keyword` from the name unless you send your own, as the response above shows. Stacks put it into the names and tags of the resources they create.
---
# Deploy a new release
URL: https://docs.webscale.com/docs/how-tos/deployment/essentials/essentials-deploy/
Description: How to deploy a new Magento or Shopware release on Webscale Essentials.



Follow these steps to deploy a new application release.

---

## Prerequisites

- [SSH Connect](/docs/how-tos/ssh-connect/) access to the Essentials server
- The branch/tag or build you want to deploy

---

## 1. Open SSH Connect and dev shell

Webscale CP > Accordion Menu (top left) > SSH Connect

Find the instance you want to connect to and open a terminal session by clicking on the instance link.

Then run:
```bash
dev
```
to jump to `php-fpm` container.

---

## 2. Go to the web root

{{< alert title="" color="info" >}}
All commands below are run inside this dev shell in `/var/www/html`.
{{< /alert >}}

```bash
cd /var/www/html
```

---

## 3. Update the code

### Example: Git-based deployment

```bash
git fetch origin
git checkout <branch-or-tag>
git pull origin <branch-or-tag>
```

---

## 4. Run deployment tasks (example)

### Magento

```bash
php bin/magento maintenance:enable && \
rm -rf generated/* \
var/view_preprocessed/* \
var/di/* \
var/cache/* \
var/page_cache/* \
pub/static/frontend/* \
pub/static/adminhtml/* && \
php bin/magento setup:upgrade && \
php bin/magento cache:clean && \
php bin/magento cache:flush && \
php bin/magento cache:enable && \
php bin/magento setup:di:compile && \
php -d memory_limit=2G bin/magento setup:static-content:deploy en_US -f --jobs=4 && \
php bin/magento maintenance:disable
```

### Shopware

```bash
# Run once to install the deployment helper if it is not installed yet
composer require --no-audit shopware/deployment-helper

# Deployment commands
vendor/bin/shopware-deployment-helper run --skip-asset-install --skip-theme-compile
php bin/console database:migrate --all
php bin/console theme:compile --sync
php bin/console theme:refresh
php bin/console cache:clear
php bin/console cache:warmup
```

---

## 5. Verify the deployment

- Load the site in a browser
- Optionally check versions:

```bash
php bin/magento --version
# or
php bin/console --version
```

---

## 6. When to contact Webscale

Contact Webscale support if:

- Database migrations fail
- Deployment completes but the site shows errors

## 7. Related how-to guides

- [Magento and Shopware commands](/docs/how-tos/Deployment/Essentials/essentials-commands/)
- [Essentials environment reference](/docs/reference/essentials-environment-reference/)
---
# Deploy a new release
URL: https://docs.webscale.com/docs/how-tos/deployment/standard/standard-deploy/
Description: How to deploy a new Magento or Shopware release on Webscale Pro V3 environments.



Webscale Pro V3 runs your application in containers with supporting services managed by Webscale. Use this guide to deploy a new release for your environment.

---

## 1. Open SSH connect and container shell

Login to the [Webscale Control Panel](https://control.webscale.com/):

- Click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left site navigation > **[SSH connect](https://control.webscale.com/ssh-connect)**
- Find the NFS instance for your environment and open a terminal session by clicking on the instance link.

---

## 2. Switch to the deployment user

On the NFS host, switch to the deployment user (for example `webscalebuilder`):

```bash
sudo -iu webscalebuilder
```

---

## 3. List available images

Use the helper script to list available images for this environment:

```bash
list-images
```

This shows a list of the available container images along with their associated tags. For example:
```bash
"sha256:5cc440543cc9acf7abfb4875ba149e5bb339b248c15507475a39f04da12f0c1c": [
        "commit-da25261-20240829-192048",
        "commit-da25261"
]
"sha256:5d9d78fdc7f6ae26861aafeec977b5db6adc9d757995a7c1b880130c18246621": [
        "commit-65d7766-20240903-192941",
        "commit-65d7766"
]
"sha256:9dd60263109cacfb16fa85d8c40ccd5e22c50ae924fb137eb76a4aa4c55b7aff": [
        "commit-1f723a4",
        "commit-1f723a4-20240904-160243"
]
```

---

## 4. Check the current deploy tag

Check which tag is currently in use:

```bash
grep DEPLOY_TAG /home/webscalebuilder/.env
```

Example output:

```text
DEPLOY_TAG=staging
```

---

## 5. Tag the new image for deployment

Choose the image you want to deploy and tag it, using [deployment helper scripts](/hosting-platforms/hosting-v3/#deployment-helper-scripts), with the deploy tag from the previous step.

The following helper scripts are available for deployments on Webscale Pro V3 environments:

### Example: tag by commit

```bash
tag-by-commit commit-<hash> <deploy-tag>
```

### Example: tag by branch

```bash
tag-by-branch branch-<name> <deploy-tag>
```

Replace `<deploy-tag>` with the value from `DEPLOY_TAG` (for example `staging` or `production`).

---

## 6. Run the deployment using run-deploy-and-cleanup

The `run-deploy-and-cleanup` script organizes the necessary actions for deployment into a single command. Running this command will:
- Pull the tagged image from above
- Apply any environment hooks if configured (migrations, cache warmups, etc.)
- Update the running containers

It is recommended to run the deployment in a `screen` session so it continues if your SSH session drops:

```bash
screen -S deploy
run-deploy-and-cleanup
```

Monitor the terminal output for any errors or warnings during the process.

Deployment logs are also available at:

```bash
/var/log/deploy/*
```

---

## 7. Verify the deployment

After `run-deploy-and-cleanup` completes:

1. Verify the site works as expected in a browser
2. Connect to a container shell
   ```bash
   shell
   ```
3. Run a quick version check using your framework-specific command:

   ```bash
   php bin/magento --version
   # or
   php bin/console --version
   ```

---

## When to contact Webscale

Contact Webscale support if:

- `run-deploy-and-cleanup` exits with an error you do not understand
- Containers are not updated to the expected image
- The site shows errors after a successful deployment

## Related how-to guides

- [Magento and Shopware commands](/docs/how-tos/Deployment/Standard/standard-commands/)
- [Standard environment reference](/hosting-platforms/hosting-v3/)
---
# Essentials
URL: https://docs.webscale.com/docs/how-tos/deployment/essentials/
Description: Deployment guides for Webscale Essentials.



Essentials runs all application and supporting services on a single instance.

Use these guides to:

- Deploy a new release
- Run Magento and Shopware CLI commands
- Look up environment-specific commands and services
---
# Essentials
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/essentials/
Description: Guide for understanding and configuring an Essentials stack



The Essentials stack provides a robust, streamlined foundation for applications
that do not yet require horizontal scaling. It provisions a comprehensive,
all-in-one environment on a single, highly optimized server.

**Architecture**: Single-server deployment.

**How it Works**: A single server accommodates the complete application stack,
including the web tier, an NFS shared filesystem, cron execution, relational
database (MySQL or MariaDB), caching (Valkey), message brokering (RabbitMQ), and
search (OpenSearch).

**Best For**: Baseline workloads, staging environments, or applications with
predictable, moderate traffic.

## Supported variants

- Magento (`type: essentials-magento`)
- Shopware (`type: essentials-shopware`)

## Variables

| Variable name | Type | Description |
| :--- | :--- | :---| :--- |
| `region` | `string` | *Required* The region to deploy the stack. |
| `zone` | `string` | Optional. Availability zone. Specify only when a specific zone is required. Otherwise, derived from the `region`. |
| `size` | `string` | *Required* Plan size. Must be one of `dev`, `micro`, `mini`, `small`, `medium`, `large`, or `xlarge`. |
| `server_size` | `object` | Optional override for core server compute. Must map to a specific ARM64 instance type based on vCPU and memory. |
| ↳`vcpu` | `number` | vCPU count. |
| ↳`memory` | `number`| GiB. |
| `data_disk_size` | `number` | Optional. The size of the data disk in GiBs. If this is provided, it will override the default disk size. |
| `db_endpoint` | `string` | Optional. Only provide when an add-on database has been created. Typically a reference to an RDS stack output. |
| `db_password_secret_name` | `string` | Optional. Only provide when an add-on database has been created. A reference to a Secrets Manager secret for retrieving the database password. Typically a reference to an RDS stack output. |
| `stacker_variables` | `object` | |
| ↳`mysql` | `object` | Optional Mysql configuration variables. See [**MySQL**](/hosting-platforms/hosting-v4/services/mysql/) for details. |
| ↳`php` | `object` | Optional PHP configuration variables. See [**PHP-FPM**](/hosting-platforms/hosting-v4/services/php-fpm/) for details. |
| ↳`vinyl` | `object` | Optional Vinyl configuration variables. See [**Vinyl**](/hosting-platforms/hosting-v4/services/vinyl/) for details. |

### Example:

```
{
  "type": "essentials-magento",
  "environment": "/v2/environments/tu8aovkn7waj",
  "service": "/v2/services/2tpkjj7e0b28",
  "name": "magento-production-store",
  "variables": {
    "region": "us-east-1",
    "size": "medium",
    "stacker_variables": {
      "php": {
        "version": "8.3"
      },
      "mysql": {
        "variant": "mariadb",
        "version": "10.5.18"
      }
    }
  }
}
```

## Outputs

| Output name | Description |
| :--- | :--- |
| `data_subnets` | Array of subnet IDs for backend services [subnet]. |
| `public_subnets` | Array of subnet IDs for public services [primary, secondary]. |
---
# IP address is not allowlisted
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/ip-address-is-not-allowlisted/
Description: Matches when the requester's IP address is absent from the allowlist.


This condition checks if the requester's IP address is missing from the Allowlist within an account's address set. It compares the address from the request to the list of addresses managed in that section of the dashboard and returns true if no match is found.

## Configuration

No further configurations are necessary for this condition. The logic is applied automatically to all addresses currently present in the Allowlist.
---
# Shared Responsibilities
URL: https://docs.webscale.com/docs/reference/shared-responsibilities/
Description: Reference for shared responsibilities.

Read the step-by-step [How-Tos](/docs/how-tos/) to learn about common tasks you can perform with your Webscale platform.

Check out the [FAQ section](/docs/faq/) for answers to commonly asked questions.
---
# Software Products
URL: https://docs.webscale.com/docs/reference/software/software-products/
Description: Full reference for CloudEDGE Security and the Webscale Platform Software tiers, including the comparison matrix, per-tier detail and the features glossary.



## CloudEDGE Security

CloudEDGE Security is the Webscale security product for customers whose
applications are hosted outside Webscale. It deploys Webscale's security layer in
front of an existing application. It provides origin protection, DDoS defense, bot
management, a Web Application Firewall, OWASP Top 10 coverage, role-based access
control, carding attack protection and data loss prevention. It does not include
the platform's performance and delivery features. Those are offered through the
Webscale Platform Software paired with a Webscale hosting plan.

### Allowances and capabilities

| Allowance | Included |
| --- | --- |
| Data Transfer | 50 GB |
| Requests | 25 M |
| Application Hostnames | 5 (guidance) |
| Elastic Data Plane | Shared |
| CDN | Included |
| Custom Web Controls | 20 |
| Traffic Viewer storage | 50 GB |
| Monitors | 5 |

Metered allowances are consumption-based above the included amount. Application
Hostnames counts are guidance. See the Application Hostnames entry in the features
glossary.

### Included security features

| Feature | Included |
| --- | --- |
| Origin Protection (App Shield) | Level 1 |
| Auto HTTPS | Included |
| Bring Your Own SSL Certificate | Included |
| Geo-blocking | Included |
| DDoS Protection | Included |
| Origin Certificates | Included |
| CSP | Included |
| Rate Limiting | Basic |
| Bot Management | Included |
| Bot Mitigation | Included |
| WAF (WAAP) | Basic |
| OWASP Protection | Included |
| Role-based Access Control | Included |
| Carding Attack Protection | Included |
| Trusted Proxies | Included |
| Secure Access | Included |
| Data Loss Prevention | Included |

### Included observability features

| Feature | Included |
| --- | --- |
| Traffic Viewer storage | 50 GB |
| Event Logs (audit) | 5 years, no additional cost |
| Session Tracking | Included |
| Real User Monitoring (RUM) | Included |
| Additional Online Logs | Included |
| Archived Logs | Included |
| Monitors | 5 |
| Custom Log Capture | Included |

### Who this product is for

Customers running an application outside Webscale who need a managed security
layer in front of it. Customers hosting on Webscale should look at the Webscale
Platform Software instead.

## Webscale Platform Software

The Webscale Platform Software is sold in four tiers. Each tier includes a fixed
set of performance, security and observability capabilities along with a defined
allowance for metered resources.

- **Essentials.** The entry Platform tier, suitable for smaller applications. It
  includes the core performance and delivery features of the platform with a basic
  security and observability baseline.
- **Advanced.** Adds dynamic site caching, image optimization, expanded Traffic
  Viewer storage, session tracking, real user monitoring, archived logs, OWASP
  protection, CSP and expanded Web Controls and Monitors allowances.
- **Premier.** Adds Site Splicing, Bot Management and Bot Mitigation, Advanced WAF,
  role-based access control, carding attack protection, data loss prevention and
  custom log capture.
- **Ultra.** Adds a dedicated elastic data plane, Level 3 origin protection,
  Advanced rate limiting, Trusted Proxies, Secure Access and the largest included
  allowances for every metered feature.

All four Platform tiers are paired with a Webscale hosting plan. The available
pairings, pricing and upgrade rules are published on webscale.com.

## Platform Software comparison matrix

### Headline allowances

| Allowance | Essentials | Advanced | Premier | Ultra |
| --- | --- | --- | --- | --- |
| Included Data Transfer | 50 GB | 250 GB | 500 GB | 1,000 GB |
| Included Requests | 25 M | 125 M | 250 M | 500 M |
| Application Hostnames | 2 | 5 | 20 | 100 |
| Elastic Data Plane | Shared | Shared | Shared | Dedicated |

All metered allowances are consumption-based above the included amount. Rates are
published on webscale.com. Application Hostnames counts are guidance. See the
Application Hostnames entry in the features glossary.

### Performance and delivery

| Feature | Essentials | Advanced | Premier | Ultra |
| --- | --- | --- | --- | --- |
| Predictive Auto-scaling | Included | Included | Included | Included |
| Self-healing | Included | Included | Included | Included |
| Load Balancing | Included | Included | Included | Included |
| Elastic Data Plane | Shared | Shared | Shared | Dedicated |
| CDN | Included | Included | Included | Included |
| Dynamic Site Cache | Not included | 1 GB | 5 GB | 10 GB |
| Dynamic Site Cache Rules | Not included | 1 | 5 | 10 |
| Custom Web Controls | Not included | 10 | 20 | 100 |
| Site Splicing | Not included | Not included | Included | Included |
| Custom Microsites | Not included | 1 (5 MB) | 5 (20 MB) | 10 (50 MB) |
| Image Optimization | Not included | 100K/mo | 200K/mo | 500K/mo |

### Security

| Feature | Essentials | Advanced | Premier | Ultra |
| --- | --- | --- | --- | --- |
| Origin Protection (App Shield) | Level 1 | Level 2 | Level 2 | Level 3 |
| Auto HTTPS | Included | Included | Included | Included |
| Bring Your Own SSL | Included | Included | Included | Included |
| Geo-blocking | Included | Included | Included | Included |
| DDoS Protection | Included | Included | Included | Included |
| Origin Certificates | Included | Included | Included | Included |
| CSP | Not included | Included | Included | Included |
| Rate Limiting | Not included | Basic | Basic | Advanced |
| Bot Management | Not included | Not included | Included | Included |
| Bot Mitigation | Not included | Not included | Included | Included |
| WAF (WAAP) | Basic | Basic | Advanced | Advanced |
| OWASP Protection | Not included | Included | Included | Included |
| Role-based Access Control | Not included | Not included | Included | Included |
| Carding Attack Protection | Not included | Not included | Included | Included |
| Trusted Proxies | Not included | Not included | Not included | Included |
| Secure Access | Not included | Not included | Not included | Included |
| Data Loss Prevention | Not included | Not included | Included | Included |

### Observability

| Feature | Essentials | Advanced | Premier | Ultra |
| --- | --- | --- | --- | --- |
| Traffic Viewer storage | 10 GB | 50 GB | 75 GB | 100 GB |
| Event Logs (audit, 5yr free) | Included | Included | Included | Included |
| Session Tracking | Not included | Included | Included | Included |
| Real User Monitoring (RUM) | Not included | Included | Included | Included |
| Additional Online Logs | Not included | Not included | Included | Included |
| Archived Logs | Not included | Included | Included | Included |
| Monitors (included) | Not included | 5 | 10 | 50 |
| Custom Log Capture | Not included | Not included | Included | Included |

Event Logs are configuration audit logs. They are retained at no additional cost
for 5 years across all products and tiers. Other Traffic Viewer log types such as
request logs and custom logs count against the tier's GB storage allowance.

### Add-ons

| Add-on | Essentials | Advanced | Premier | Ultra |
| --- | --- | --- | --- | --- |
| Varnish | Optional | Optional | Optional | Optional |

## Per-tier detail

Each tier follows the same template: a positioning paragraph, headline allowances,
a note on who the tier is for and a pointer to the features glossary for full
feature definitions.

### Essentials

Essentials is the entry Webscale Platform tier. It includes the core performance
and delivery capabilities of the platform such as predictive auto-scaling,
self-healing, load balancing and CDN, along with a baseline security layer
covering Auto HTTPS, Bring Your Own SSL, geo-blocking, DDoS protection, origin
certificates and basic WAF. It is intended for smaller applications and
lower-traffic workloads.

| Allowance | Included |
| --- | --- |
| Included Data Transfer | 50 GB |
| Included Requests | 25 M |
| Application Hostnames | 2 (guidance) |
| Elastic Data Plane | Shared |
| CDN | Included |
| Custom Web Controls | 0 |
| Traffic Viewer storage | 10 GB |
| Monitors | 0 |

**Who this tier is for.** Customers running smaller applications who need
Webscale's hosting and core delivery features with a baseline security and
observability layer. Customers needing dynamic site caching, image optimization,
expanded Traffic Viewer storage, RUM or stronger security should consider
Advanced.

### Advanced

Advanced is the mid Platform tier. It builds on Essentials by adding dynamic site
caching at 1 GB, image optimization at 100K transforms per month, expanded Traffic
Viewer storage, session tracking, real user monitoring, archived logs, OWASP
protection, CSP support, Level 2 origin protection, basic rate limiting and 10
Custom Web Controls and Monitors.

| Allowance | Included |
| --- | --- |
| Included Data Transfer | 250 GB |
| Included Requests | 125 M |
| Application Hostnames | 5 (guidance) |
| Elastic Data Plane | Shared |
| CDN | Included |
| Dynamic Site Cache | 1 GB (1 rule) |
| Custom Microsites | 1 (up to 5 MB) |
| Image Optimization | 100K transforms/month |
| Custom Web Controls | 10 |
| Traffic Viewer storage | 50 GB |
| Monitors | 5 |
| Origin Protection | Level 2 |

**Who this tier is for.** Mid-sized applications needing serious performance,
baseline security and full observability. Customers needing Site Splicing, bot
management, advanced WAF, role-based access control, carding attack protection or
data loss prevention should consider Premier.

### Premier

Premier is the upper Platform tier, suitable for high-traffic applications with
substantive performance, security and observability needs. It adds Site Splicing,
Bot Management and Bot Mitigation, Advanced WAF, role-based access control, carding
attack protection, data loss prevention and custom log capture.

| Allowance | Included |
| --- | --- |
| Included Data Transfer | 500 GB |
| Included Requests | 250 M |
| Application Hostnames | 20 (guidance) |
| Elastic Data Plane | Shared |
| CDN | Included |
| Dynamic Site Cache | 5 GB (5 rules) |
| Custom Microsites | 5 (up to 20 MB) |
| Image Optimization | 200K transforms/month |
| Custom Web Controls | 20 |
| Traffic Viewer storage | 75 GB |
| Monitors | 10 |
| WAF | Advanced |
| Origin Protection | Level 2 |

**Who this tier is for.** High-traffic applications needing the platform's full
delivery and security capabilities at substantial scale but able to operate on a
shared data plane. Customers needing a dedicated data plane, Level 3 origin
protection, advanced rate limiting, trusted proxies or secure access should
consider Ultra.

### Ultra

Ultra is the top Platform tier. It is differentiated from Premier by a dedicated
elastic data plane, Level 3 origin protection, Advanced rate limiting, trusted
proxies and secure access, along with the largest included allowances for every
metered feature. Ultra is intended for the highest-traffic and most
security-sensitive applications on the Webscale platform.

| Allowance | Included |
| --- | --- |
| Included Data Transfer | 1,000 GB |
| Included Requests | 500 M |
| Application Hostnames | 100 (guidance) |
| Elastic Data Plane | Dedicated |
| CDN | Included |
| Dynamic Site Cache | 10 GB (10 rules) |
| Custom Microsites | 10 (up to 50 MB) |
| Image Optimization | 500K transforms/month |
| Custom Web Controls | 100 |
| Traffic Viewer storage | 100 GB |
| Monitors | 50 |
| WAF | Advanced |
| Origin Protection | Level 3 |
| Rate Limiting | Advanced |

**Who this tier is for.** Customers with the highest performance, isolation and
security requirements, including those who require a dedicated data plane for
compliance or traffic isolation reasons.

## Features glossary

This section is the educational feature reference. Each feature is defined once and
used identically across CloudEDGE Security, the Platform comparison matrix and the
per-tier detail.

### Performance and delivery

| Feature | Definition | Available in |
| --- | --- | --- |
| Predictive Auto-scaling | Uses automation and predictive analytics to increase or decrease application resources to maintain consistent performance without over-allocation. | All Platform tiers. Not in CloudEDGE Security. |
| Self-healing | An extension of auto-scaling that ensures failed application components are promptly replaced to avoid timeouts and error pages. | All Platform tiers. Not in CloudEDGE Security. |
| Load Balancing | Actively distributes requests across application servers and routes around servers experiencing performance or availability issues. | All Platform tiers. Not in CloudEDGE Security. |
| Elastic Data Plane | The intermediary between web browsers and your application. A shared data plane uses IP addresses socialized with other applications. A dedicated data plane uses addresses unique to your application and can deploy data plane assets into a public subnet of your own VPC for enhanced security. | Shared on CloudEDGE Security, Essentials, Advanced and Premier. Dedicated on Ultra. |
| CDN | A globally distributed set of servers that delivers cacheable content from a location close to the visitor, reducing latency and origin load. Includes standard caching rules for static content and media. Additional caching behavior can be configured using Custom Web Controls. | All products. |
| Application Hostnames | The hostnames to which an application responds. No hard limit is enforced today. Included counts are guidance. Auto HTTPS provisions one certificate per group of up to roughly 150 hostnames. | CloudEDGE Security 5, Essentials 2, Advanced 5, Premier 20, Ultra 100. |
| Data Transfer | The aggregate volume of data delivered through the Webscale Data Plane to end users in a billing period. Overage is consumption-based. | All products. 50, 50, 250, 500, 1,000 GB. |
| Included Requests | Total number of HTTP requests handled by the Webscale Data Plane in a billing period. Overage is consumption-based. | All products. 25 M, 25 M, 125 M, 250 M, 500 M. |
| Dynamic Site Cache | A cache located in the Webscale Data Plane that provides extremely fast access near application servers. Combined with the CDN it can substantially reduce origin load. | Advanced 1 GB, Premier 5 GB, Ultra 10 GB. |
| Dynamic Site Cache Rules | Rules that determine what is cacheable, for how long and on which browser or user-state. Multiple cache versions of the same resource can be maintained by request characteristics. | Advanced 1, Premier 5, Ultra 10. |
| Custom Web Controls | A configurable policy and rules engine in the Webscale Portal that combines conditions with actions applied to requests proxied by the Data Plane. Used for both security and performance customization. | CloudEDGE Security 20, Advanced 10, Premier 20, Ultra 100. Not in Essentials. |
| Site Splicing | Combines multiple origins into a single site, allowing different application components to serve specific paths or roles within one customer-facing site. | Premier, Ultra. |
| Custom Microsites | Allows content to be injected into a site without modifying the application. For PWA or headless applications, microsites can serve the entire application. | Advanced 1 site up to 5 MB, Premier 5 sites up to 20 MB, Ultra 10 sites up to 50 MB. |
| Image Optimization | Automated image management that delivers an appropriately sized image to each device, served from the nearest cache. Overage is consumption-based. | Advanced 100K/mo, Premier 200K/mo, Ultra 500K/mo. |

### Security

| Feature | Definition | Available in |
| --- | --- | --- |
| Origin Protection (App Shield) | Because the Data Plane sits between users and the application, application servers are not directly exposed. Level 1 hides server addresses behind the Data Plane. Level 2 manages a cloud Security Group or Firewall so only Webscale proxies can connect. Level 3 places a dedicated Data Plane on the same private network as application servers, isolating them from the internet. | Level 1 on CloudEDGE Security and Essentials. Level 2 on Advanced and Premier. Level 3 on Ultra. |
| Auto HTTPS | Webscale automatically obtains and renews site certificates so HTTPS is always functional. Adding a new hostname triggers automatic certificate handling. | All products. |
| Bring Your Own SSL Certificate | The Data Plane supports management of one or more customer-provided certificates alongside Auto HTTPS. | All products. |
| Geo-blocking | Requests are geo-located by origin country and Web Controls rules can allow or block access by country. | All products. |
| DDoS Protection | Always-on protection that limits the maximum number of concurrent requesters and uses dynamic address sets to block repeat requesters. Predictive Auto-scaling of the Data Plane absorbs the attacks. | All products. |
| Origin Certificates | Long-lasting certificates that protect communication from the Data Plane to application servers, avoiding downtime caused by unexpected expiry of publicly trusted certificates. | All products. |
| CSP (Content Security Policy) | Over-the-top CSP support independent of the application's implementation, separating policy from the site so injected attacks cannot succeed. | CloudEDGE Security, Advanced, Premier, Ultra. Not in Essentials. |
| Rate Limiting | Rejects requests from a single source that exceed a defined rate for a defined blocking period. Basic provides a built-in rate with automatic enforcement. Advanced provides per-area configurable rates and configurable blocking periods. | Basic on CloudEDGE Security, Advanced and Premier. Advanced on Ultra. Not in Essentials. |
| Bot Management | Separates legitimate bots from malicious ones using Webscale-provided, dynamically updated Address Sets. Automatically detects and categorizes malicious bot behavior. | CloudEDGE Security, Premier, Ultra. |
| Bot Mitigation | A coordinated set of mechanisms for distinguishing automated traffic from legitimate users and challenging or blocking suspect requests. Today it is delivered as a combination of reCAPTCHA integration, user-agent classification rules configured in Web Controls and forthcoming ASN-level blocking. These mechanisms will be unified under a single feature surface in a future UI release. | CloudEDGE Security, Premier, Ultra. |
| WAF (WAAP) | The Cloud WAF protects applications by examining HTTP requests and blocking or modifying malicious ones. Basic provides automatic blocking of known attack signatures. Advanced provides custom configurable conditions for advanced attacks. | Basic on CloudEDGE Security, Essentials and Advanced. Advanced on Premier and Ultra. |
| OWASP Protection | Automated protection against the OWASP Top 10 and other common web vulnerabilities such as SQL Injection, XSS and CSRF. | CloudEDGE Security, Advanced, Premier, Ultra. Not in Essentials. |
| Role-based Access Control (RBAC) | Fine-grained permission assignment for users managing application configurations and other resources. | CloudEDGE Security, Premier, Ultra. |
| Carding Attack Protection (CAP) | Uses knowledge of user behavior on e-commerce sites to recognize and stop carding attacks before they occur. | CloudEDGE Security, Premier, Ultra. |
| Trusted Proxies | Allows another technology in front of the Data Plane to be registered as trusted, so requests passing through it are correctly identified and can be restricted to come only from a trusted proxy. | CloudEDGE Security, Ultra. |
| Secure Access | Role-based permissions applied to sections of the application to restrict access from the general internet to authenticated, role-authorized users. | CloudEDGE Security, Ultra. |
| Data Loss Prevention | Prevents exfiltration of data by limiting access or request volume to sensitive parts of the site. | CloudEDGE Security, Premier, Ultra. |

### Observability

| Feature | Definition | Available in |
| --- | --- | --- |
| Traffic Viewer | A real-time view inside the Webscale Portal of CDN requests, application server requests, Data Plane requests, monitor-generated events, configuration changes and custom application logs. Storage is measured in gigabytes and retention duration is configurable per application and account. | All products. |
| Event Logs (configuration audit) | Logs that record configuration changes and access to the Webscale platform, including who made what changes and when. These are the platform's audit trail. | All products. Retained 5 years at no additional cost. |
| Session Tracking | Automatically tracks user sessions and makes session IDs available in the Traffic Viewer so requests belonging to a session can be analyzed together. | CloudEDGE Security, Advanced, Premier, Ultra. |
| Real User Monitoring (RUM) | Collects performance data from end users' browsers to inform Core Web Vitals tuning and measure the impact of site changes. | CloudEDGE Security, Advanced, Premier, Ultra. |
| Additional Online Logs | All online logs are viewed via the Traffic Viewer. Online log storage counts against the Traffic Viewer GB allowance for the tier and retention is configurable. | CloudEDGE Security, Premier, Ultra. |
| Archived Logs | Logs that no longer need to be viewable in the Traffic Viewer but must be retained for audit. Available for download via API. Archived log storage is billed on consumption separately from Traffic Viewer storage. | CloudEDGE Security, Advanced, Premier, Ultra. |
| Monitors | A configurable observer of an application component, used to notify or take action when a condition is met, for example average response time exceeding a threshold for critical pages. | CloudEDGE Security 5, Advanced 5, Premier 10, Ultra 50. Not in Essentials. |
| Custom Log Capture | A feature of the Webscale Monitoring Agent that captures logs from files in real-time and stores them as online custom logs viewable in the Traffic Viewer. Captured logs count against the tier's Traffic Viewer GB allowance. | CloudEDGE Security, Premier, Ultra. |

### Add-ons

| Feature | Definition | Available in |
| --- | --- | --- |
| Varnish | An industry-standard caching solution integrated completely with Webscale's core features. Webscale operates and maintains the Varnish layer so customers receive its caching benefits with zero maintenance overhead and automatic failover. | Optional on all Platform tiers. Not offered with CloudEDGE Security. |
---
# Support Packages & Service Matrix
URL: https://docs.webscale.com/docs/reference/support/support-packages/
Description: The full tier-by-tier Webscale support matrix — channels, incident response, onboarding, monitoring, developer enablement, reviews, and the DevOps add-on.



Webscale support is sold in three tiers, independently of the hosting and
infrastructure product tiers:

- **Tier 1 — Essentials Support.** Standard single-ticket coverage.
- **Tier 2 — Proactive Support.** Expanded response and engineering.
- **Tier 3 — Strategic Support.** White-glove; high-availability (HA) available.

Incident commitments are defined by priority: **P0 Urgent** (site down),
**P1 High** (degraded performance), **P2 Normal** (non-emergency), and
**P3 Low** (information or minor issue).

## Support channels

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Ticket Portal** — Standard support ticketing system | Yes | Yes | Yes |
| **Dedicated Slack Channel** — Private real-time support channel | No | No | Yes |
| **Phone Support** — Direct line for critical escalations | No | No | Yes |
| **Dedicated Support SME** — Named SME with dedicated hrs/month; guardrails apply, not 24/7 | No | No | Yes |

## Incident response

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Monthly Incident Volume** — Included P0 tickets/month (customer-opened only; alert tickets excluded) | 10 P0 tickets / month | 25 P0 tickets / month | Unlimited P0 tickets / month |
| **Incident First Response** — Committed initial response time by priority | P0 30 min · P1 4 hrs · P2 8 hrs · P3 16 hrs | P0 30 min · P1 2 hrs · P2 4 hrs · P3 8 hrs | P0 15 min · P1 30 min · P2 2 hrs · P3 4 hrs |
| **Response Update Interval** — Update cadence during active incidents | P0 2 hrs · P1 4 hrs · P2 8 hrs · P3 16 hrs | P0 60 min · P1 2 hrs · P2 4 hrs · P3 8 hrs | P0 15 min · P1 30 min · P2 2 hrs · P3 4 hrs |

## Onboarding support

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Onboarding Hours Included** — Initial environment setup only; additional environments billed separately (first 90 days) | 2 hrs included | 8 hrs included | 16–32 hrs (Tier 3 / HA) |
| **Dedicated Onboarding Engineer** — Named engineer assigned to your launch | No | No | Yes |

## Platform monitoring

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Active Monitoring Coverage** — Areas covered 24/7 by the Webscale SDS team | Uptime · Basic Alerts · Error Rate | Uptime · Alerts · Error Rate · Performance · CDN Health | Uptime · Alerts · Error Rate · Performance · CDN Health · Cache Hit Rate · Database · Container Health · Security Events · Traffic Anomalies · Availability Zones · Custom Dashboards · Proactive Alerting · Synthetic Monitoring · Business KPI Tracking |
| **App Monitoring Setup Assistance** — Help configuring your monitoring stack | No | No | Yes |
| **Event Preparation & Monitoring** — Peak season / launch event coverage (see note 8) | No | No | Yes |

## Developer Enablement (DE) access

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Monthly DE Hours** — Code review, troubleshooting and platform-level engineering | None | 4 hrs / month | 10–20 hrs / month (Tier 3 / HA) |

## Reviews & audits

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Product Update Reviews** — Scheduled review of platform and product updates | Yes | Yes | Yes |
| **Environment Audit** — Moved to add-on services (see the DevOps add-on below) | See add-on | See add-on | See add-on |
| **Monthly Business Review (MBR)** — Performance summary, incident review and roadmap | Not included | Not included | Yes |
| **Control Panel Configuration Review** — Expert review and optimization of the control panel | Not included | Not included | Yes |

## Platform add-ons — included on all plans

| Feature | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Virus / Malware Scanning** — Automated security scanning on all environments | Yes | Yes | Yes |
| **Backups — Every 24 Hours** — Daily automated environment backups | Yes | Yes | Yes |

## DevOps support add-on

| Add-on service | Tier 1 · Essentials | Tier 2 · Proactive | Tier 3 · Strategic |
| --- | --- | --- | --- |
| **Event Preparation & Monitoring** — 10-hour buckets for Tier 1 and Tier 2 (see note 8) | 10 hr bucket | 10 hr bucket | Included |
| **Short-Term Scaling Upgrades** — Temporary capacity for peaks or launches | 10 hr bucket | 10 hr bucket | 10 hr bucket |
| **Application Load Testing Assistance** — Performance validation before go-live (see note 9) | 10 hr bucket | 10 hr bucket | 10 hr bucket |
| **Environment Audit (new)** — Infrastructure / coding / best practices; per-request, billed as professional services | On request | On request | On request |

## Notes & definitions

1. Support tiers are sold independently of hosting and infrastructure product tiers.
2. Tier 3 HA includes a fully redundant high-availability infrastructure configuration in the backend.
3. Monthly incident volume limits apply to P0 (customer-opened) tickets only; system alert tickets are excluded.
4. Onboarding hours cover the initial environment setup within the first 90 days. Additional environments are billed separately as a one-time implementation cost.
5. Dedicated Support SME (Tier 3) includes a defined number of dedicated hours per month; guardrails and schedules apply — not an on-demand 24/7 resource.
6. DE (Developer Enablement) hours are pooled monthly and do not roll over.
7. Environment Audits are no longer tiered — available as a per-request add-on billed as professional services.
8. Event Preparation & Monitoring is included at Tier 3; a 10-hour bucket add-on for Tier 1 and Tier 2.
9. Application Load Testing and the DevOps package are available as add-ons.
---
# IP address is a threat
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/ip-address-is-a-threat/
Description: Matches when the requester's IP address is a known malicious source.


This condition inspects the client IP address of an incoming request to determine if it is a known malicious source. It returns true if the address matches an entry in the threat database.

## Configuration

* **Bot IP shield**: This condition requires the Bot IP Shield add-on to be active for the application.
* **Setup**: No further configurations are necessary for this condition. The underlying threat data is automatically updated via [Webroot’s BrightCloud® IP Reputation Service](https://www.brightcloud.com/) every five minutes to reflect the latest global attack sources.

## Measurement

The condition resolves the IP address from the incoming request and evaluates it against the threat reputation database.

* **Database lookup**: The reputation service is queried to determine if the IP address is categorized as a known threat.
* **Error handling**: If the reputation service returns an error or cannot be reached, the condition returns false.
* **Logging**: The threat status of the IP address is recorded in the application logs for visibility.

The condition returns true if the IP address is successfully identified as a known threat.
---
# IP address is not a threat
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/ip-address-is-not-a-threat/
Description: Matches when the requester's IP address is not a known malicious source.


This condition inspects the client IP address of an incoming request to verify it is not a known malicious source. It returns true if the address is absent from the threat database.

## Configuration

* **Bot IP shield**: This condition requires the Bot IP Shield add-on to be active for the application.
* **Setup**: No further configurations are necessary for this condition. The underlying threat data is automatically updated via [Webroot’s BrightCloud® IP Reputation Service](https://www.brightcloud.com/) every five minutes to reflect the latest global attack sources.

## Measurement

The condition resolves the IP address from the incoming request and evaluates it against the threat reputation database.

* **Database lookup**: The reputation service is queried to determine if the IP address is categorized as a known threat.
* **Error handling**: If the reputation service returns an error or cannot be reached, the condition returns true.
* **Logging**: The threat status of the IP address is recorded in the application logs for visibility.

The condition returns true if the IP address is confirmed as not being a known threat.
---
# Random
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/random/
Description: Matches a specified percentage of traffic based on a random selection.


This condition triggers actions randomly based on a specified percentage of traffic.

## Configuration

* **Percentage of traffic**: A numerical value between 0 and 100 that defines the likelihood of the condition matching. A value of 0 will never return true, while a value of 100 will always return true. This field is required.

## Measurement

For every incoming request, the condition evaluates a uniform random float between `0.0` and `1.0`. The configured **Percentage of traffic** is converted to a probability (e.g. 20% becomes `0.2`). The condition returns true if the generated random value is less than this probability.
---
# Rate limit
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/rate-limit/
Description: Matches when requests for a specific client exceed a defined threshold within a set duration.


This condition tracks the volume of requests from a specific requester and returns true if that volume exceeds a defined threshold within a set time period. Rate counters are measured centrally across all proxies serving an application, and each evaluated client ID is allocated its own counter as long as requests are received for it within the interval.

Counting only occurs if the other conditions within the web control are met. The counter set for a rate limit condition is unique to the specific web control that contains it; an identical condition in another web control maintains its own independent counter set.

## Configuration

* **Client ID**: A [value template](https://control.webscale.com/docs/api#:~:text=value%20template) evaluated to identify the requester. By default, this is set to `$(request_address)` to track by the requester's IP address. This field is required.
* **Threshold**: The maximum number of requests allowed within the duration before the condition triggers. This must be a number greater than 0. This field is required.
* **Duration**: The amount of time over which to accumulate the request count. This must be a number of at least 5 when the unit of time is seconds, but can be as low as 1 if the unit of time is minutes or hours. This field is required.
* **Unit**: The unit of time (Seconds, Minutes, or Hours) used for the duration. This field is required.

## Measurement

Rate measurement is not exact. For efficiency, a sliding window is used with a fixed number of buckets. While a triggered condition confirms the client is over the limit, a client strictly over the limit may be measured under the limit if a significant number of requests fall at the beginning of the interval.
---
# Standard
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/standard/
Description: Guide for understanding and configuring a Standard stack



The Standard stack introduces dynamic capacity by decoupling the web delivery
layer from the backend services.

**Architecture**: An autoscaling web tier supported by a single "core" server.

**How it Works**: The web server is moved into a horizontally scaling layer that
automatically expands or contracts based on real-time request demand. The core
server processes and manages common backend services (databases, caching,
search, NFS, and cron).

**Best For**: Applications prone to traffic spikes or those experiencing rapid
growth that require immediate, automated scaling at the web tier.


## Supported variants

- Magento (`type: standard-magento`)
- Shopware (`type: standard-shopware`)

## Variables

| Variable name | Type | Description |
| :--- | :--- | :---| :--- |
| `region` | `string` | *Required* The region to deploy the stack. |
| `zone` | `string` | Optional. Availability zone. Specify only when a specific zone is required. Otherwise, derived from the `region`. |
| `size` | `string` | *Required* Plan size. Must be one of `dev`, `micro`, `mini`, `small`, `medium`, `large`, or `xlarge`. |
| `server_size` | `object` | Optional override for core server compute. Must map to a specific ARM64 instance type based on vCPU and memory. |
| ↳`vcpu` | `number` | vCPU count |
| ↳`memory` | `number`| GiB |
| `cluster_size` | `object` | Optional override for cluster server compute. Must map to a specific ARM64 instance type based on vCPU and memory. |
| ↳`vcpu` | `number` | vCPU count. |
| ↳`memory` | `number`| GiB. |
| `data_disk_size` | `number` | Optional. The size of the data disk in GiBs. If this is provided, it will override the default disk size. |
| `db_endpoint` | `string` | Optional. Only provide when an add-on database has been created. Typically a reference to an RDS stack output. |
| `db_password_secret_name` | `string` | Optional. Only provide when an add-on database has been created. A reference to a Secrets Manager secret for retrieving the database password. Typically a reference to an RDS stack output. |
| `stacker_variables` | `object` | |
| ↳`mysql` | `object` | Optional Mysql configuration variables. See [**MySQL**](/hosting-platforms/hosting-v4/services/mysql/) for details. |
| ↳`php` | `object` | Optional PHP configuration variables. See [**PHP-FPM**](/hosting-platforms/hosting-v4/services/php-fpm/) for details. |
| ↳`vinyl` | `object` | Optional Vinyl configuration variables. See [**Vinyl**](/hosting-platforms/hosting-v4/services/vinyl/) for details. |
| ↳`share` | `list(string)` | A list of specific subdirectory paths within the core server's file system to bind-mount into the application container's web root. <br> Example: `"share":["html/app/etc/env.php","html/pub/media","html/var"]`|

### Example:

```
{
  "type": "standard-magento",
  "environment": "/v2/environments/tu8aovkn7waj",
  "service": "/v2/services/2tpkjj7e0b28",
  "name": "magento-production-store",
  "variables": {
    "region": "us-east-1",
    "size": "medium",
    "stacker_variables": {
      "php": {
        "version": "8.3"
      },
      "mysql": {
        "variant": "mariadb",
        "version": "10.5.18"
      },
      "share": ["html/app/etc/env.php","html/pub/media","html/var"]
    }
  }
}
```


## Outputs

| Output name | Description |
| :--- | :--- |
| `data_subnets` | Array of subnet IDs for backend services [subnet]. |
| `public_subnets` | Array of subnet IDs for public services [primary, secondary]. |
---
# Referrer is
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/referrer-is/
Description: Matches when the Referer request header matches one or more specified wildcard patterns.


This condition inspects the `Referer` request header to determine if it matches a specified list of wildcard patterns. It returns true if the header value matches any of the defined patterns.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match against the `Referer` header sent in the request.
* **Referrer pattern**: The input field used to add new wildcard patterns. Multiple entries can be added simultaneously by separating them with a comma, a pipe (`|`), or a new line.
* **Defined patterns**: The list of all active patterns for this condition. The condition returns true if the requester's referrer matches any entry in this list.

## Pattern matching

The system supports flexible wildcard entries to simplify configuration. To ensure comprehensive matching, the system automatically translates wildcard entries into optimized regular expressions during processing:

* **Automatic conversion**: Hostname-only patterns (e.g. `*example*`) are automatically converted to `*://*example*` to match any protocol.
* **Explicit patterns**: You may provide full URLs or specific paths using wildcards (e.g. `https://example.com/path/*`).

## Measurement

The condition extracts the `Referer` header from the incoming request and evaluates it against the **Defined patterns**.

* **Match found**: If the header value matches any pattern in the list, the condition returns true.
* **No match found**: If the header value matches none of the patterns, the condition returns false.
* **Missing header**: If the `Referer` header is absent from the request, the condition returns false.

## Performance

* **Sequential validation**: Evaluation time increases incrementally with the number of patterns in the list. For requests that do not match any pattern, the system must evaluate every entry before returning false.
* **Short-circuit optimization**: The condition iterates through the list and returns true as soon as the first match is identified. To minimize processing time, place the most frequently matched patterns at the top of the list.
---
# Referrer is not
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/referrer-is-not/
Description: Matches when the Referer request header does not match any wildcard patterns.


This condition inspects the `Referer` request header to determine if it does not match a specified list of wildcard patterns. It returns true if the header value matches none of the defined patterns.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match against the `Referer` header sent in the request.
* **Referrer pattern**: The input field used to add new wildcard patterns for exclusion. Multiple entries can be added simultaneously by separating them with a comma, a pipe (`|`), or a new line.
* **Defined patterns**: The list of all active patterns for this condition. The condition returns true only if the requester's referrer matches none of the entries in this list.

## Pattern matching

The system supports flexible wildcard entries to simplify configuration. To ensure comprehensive matching, the system automatically translates wildcard entries into optimized regular expressions during processing:

* **Automatic conversion**: Hostname-only patterns (e.g. `*example*`) are automatically converted to `*://*example*` to match any protocol.
* **Explicit patterns**: You may provide full URLs or specific paths using wildcards (e.g. `https://example.com/path/*`).

## Measurement

The condition extracts the `Referer` header from the incoming request and evaluates it against the **Defined patterns**.

* **Match found**: If the header value matches any pattern in the list, the condition returns false.
* **No match found**: If the header value matches none of the patterns, the condition returns true.
* **Missing header**: If the `Referer` header is absent from the request, the condition returns true.

## Performance

* **Sequential validation**: To return true, the system must evaluate the entire list of patterns to ensure no matches exist. Large lists add an incremental processing cost to every request that passes through the filter.
* **Short-circuit optimization**: The system stops processing and returns false as soon as it identifies a match. To optimize performance for traffic that should be excluded, place the patterns most likely to match at the top of the list.
---
# Referrer is defined
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/referrer-is-defined/
Description: Matches when the Referer request header matches one or more application aliases.


This condition checks if the `Referer` header sent in the request matches any of the aliases associated with the application. It returns true if the requester's referrer hostname is recognized as an application alias.

## Configuration

No further configurations are necessary for this condition. The logic is applied automatically by comparing the request header against the application's current list of aliases.

## Measurement

The condition extracts the hostname from the `Referer` header of the incoming request. It then performs a lookup against the list of aliases configured for the application and returns true if a match is found. This is commonly used to identify traffic originating from within the same application.
---
# Referrer is not defined
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/referrer-is-not-defined/
Description: Matches when the Referer request header does not match any application aliases.


This condition checks if the `Referer` header sent in the request does not match any of the aliases associated with the application. It returns true if the requester's referrer hostname is not recognized as an application alias.

## Configuration

No further configurations are necessary for this condition. The logic is applied automatically by comparing the request header against the application's current list of aliases.

## Measurement

The condition extracts the hostname from the `Referer` header of the incoming request. It then performs a lookup against the list of aliases configured for the application and returns true if no match is found. This is commonly used to identify traffic originating from outside the application.
---
# Request header value matches
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/request-header-value-matches/
Description: Matches when the value of a specific request header matches a regular expression.


This condition inspects the value of a specified header sent in the request to determine if it matches a [regular expression](https://www.regular-expressions.info/). It returns true if the named header contains a value that matches the defined pattern.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the name and value comparison. When disabled, the condition performs a case-insensitive match for the header name and evaluates the pattern against all headers sent in the request that match that name.
* **Name**: The exact name of the request header to inspect. This field is required and supports a maximum of 50 characters.
* **Pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the header's value. The condition returns true if the pattern matches the value of the specified header. This field is required and supports a maximum of 255 characters.

## Measurement

The condition extracts all values for the specified header name from the incoming request and evaluates them against the configured pattern.

* **Match found**: If any instance of the header matches the regular expression, the condition returns true.
* **No match found**: If none of the header values match the pattern, the condition returns false.
* **Missing header**: If the specified header is absent from the request, the condition returns false.
---
# Magento and Shopware commands
URL: https://docs.webscale.com/docs/how-tos/deployment/essentials/essentials-commands/
Description: How to run Magento and Shopware CLI commands on Webscale Essentials.



Use the `dev` helper to run Magento and Shopware commands inside the application container.

---

## 1. Open SSH Connect and dev shell

In Webscale CP:

- Accordion Menu (top left) > [SSH Connect](/docs/how-tos/ssh-connect/)
- Find the instance you want to connect to and open a terminal session by clicking on the instance link.

Then run:

```bash
dev
```

to jump to the `php-fpm` container.

{{< alert title="" color="info" >}}
All commands below are run inside this dev shell in `/var/www/html`.
{{< /alert >}}

---

## 2. Magento commands

### Pattern

```bash
php bin/magento <command>
```

### Common examples

```bash
php bin/magento cache:flush
php bin/magento indexer:reindex
php bin/magento setup:upgrade --keep-generated
php bin/magento setup:static-content:deploy en_US -f --jobs=4
```

---

## 3. Shopware commands

### Pattern

```bash
php bin/console <command>
```

### Common examples

```bash
php bin/console database:migrate --all
php bin/console cache:clear:all
php bin/console cache:warmup
php bin/console theme:compile
```

---

## 4. Related how-to guides

- [Deploy a new release](/docs/how-tos/Deployment/Essentials/essentials-deploy/)
- [Essentials environment reference](/docs/reference/essentials-environment-reference/)
---
# Magento and Shopware commands
URL: https://docs.webscale.com/docs/how-tos/deployment/standard/standard-commands/
Description: How to run Magento and Shopware CLI commands on Webscale Pro V3 environments.



Use your environment-specific shell helper to run Magento and Shopware commands inside the application container.

---

## 1. Open SSH connect and container shell

Login to the [Webscale Control Panel](https://control.webscale.com/):

- Click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left site navigation > **[SSH connect](https://control.webscale.com/ssh-connect)**
- Find the NFS / web worker instance for your environment and open a terminal session by clicking on the instance link.

##### On the NFS host

Run the shell helper script:

```bash
shell
```

This opens a shell inside the application container as the appropriate user with the site code mounted.

##### On the web worker host

Identify container:

```bash
docker ps
```

Using obtained container ID you can review container logs, ssh to container, etc.

```bash
docker logs -f <container-id>
docker exec -it <container-id> bash
```

---

## 2. Quick cheat sheet

| Task          | Command                           | Common examples |
|---------------|-----------------------------------|-----------------|
| Magento CLI   | `php bin/magento <command>`       | `php bin/magento cache:flush`<br>`php bin/magento indexer:reindex` |
| Shopware CLI  | `php bin/console <command>`       | `php bin/console database:migrate --all`<br>`php bin/console cache:clear:all`<br>`php bin/console cache:warmup` |

## Related how-to guides

- [Deploy a new release](/docs/how-tos/Deployment/Standard/standard-deploy/)
- [Standard environment reference](/hosting-platforms/hosting-v3/)
---
# Create an EKS stack
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/how-tos/create-an-eks-stack/
Description: How to create an EKS stack with the Webscale API.



Follow these steps to create an EKS stack and prepare it for Helm deployments.

## Prerequisites

- **Access key:** An access key for the account, created in the **Access keys** section of your **Profile** page. See [Webscale service users](/docs/how-tos/general/service-users/) for a key that belongs to automation.
- **AWS provider:** An AWS provider in the account. See [Working with Providers](/docs/how-tos/general/providers/).
- **Environment:** An environment to hold the stack. See [Create an environment](/hosting-platforms/hosting-v4/how-tos/create-an-environment/).
- **Network:** Subnet IDs when you bring a network you already have. A new network does not need them. See [Network topology](/hosting-platforms/hosting-v4/stacks/eks/#network-topology).
- **Name:** A name for the stack, which becomes the name of the EKS cluster. It must be unique within the environment and among the stacks that share your AWS account. Use 3 to 30 characters from `a-z`, `0-9`, and `-`, starting with a lowercase letter or a digit.

Every request goes to `https://api.webscale.com` and carries the access key:

```
ACCESS_KEY=<my-access-key>
```

## 1. Find the environment

```
curl -s "https://api.webscale.com/v2/environments" \
  -H "Authorization: Bearer $ACCESS_KEY"
```

```
[
  {
    "href": "/v2/environments/3ps666yxcanq",
    "name": "Production",
    ...
  }
]
```

Note the `href` of the environment the stack belongs to. An empty list means the account has no environment. See [Create an environment](/hosting-platforms/hosting-v4/how-tos/create-an-environment/).

## 2. Find the AWS service

Saving an AWS provider creates the service that lets a stack build in your AWS account. The service takes the name of the provider.

```
curl -s "https://api.webscale.com/v2/services" \
  -H "Authorization: Bearer $ACCESS_KEY"
```

```
[
  {
    "href": "/v2/services/u91dkrui39cj",
    "category": "vm",
    "type": "aws",
    "name": "AWS production"
  },
  {
    "href": "/v2/services/2tk18ei6581v",
    "category": "cloud",
    "type": "aws",
    "name": "AWS production",
    ...
  }
]
```

Note the `href` of the entry whose `category` is `vm` and whose `type` is `aws`.

## 3. Create the stack

The stack has two network modes, and each takes a different request body. Save the one you want as `stack.json` and fill in your own environment, service, name, and network values. See [Network topology](/hosting-platforms/hosting-v4/stacks/eks/#network-topology) for the differences between the modes and [Variables](/hosting-platforms/hosting-v4/stacks/eks/#variables) for the other variables.

Either body can also set `api_ingress_cidrs` in `variables`. Add the networks you connect from, so tools such as `kubectl` or Helm reach the EKS cluster's public API endpoint. Only the Webscale Control Plane reaches the endpoint otherwise. See [Cluster access](/hosting-platforms/hosting-v4/stacks/eks/#cluster-access).

### Existing network

The stack puts the nodes and the EKS cluster's API in subnets you already have, all in one VPC. It opens the NodePort range to that VPC's primary CIDR block and nothing else. Add any other network to `service_ingress_cidrs`.

```
{
  "type": "eks",
  "environment": "/v2/environments/3ps666yxcanq",
  "service": "/v2/services/u91dkrui39cj",
  "name": "production-eks",
  "variables": {
    "region": "us-east-1",
    "node_subnets": ["subnet-0123456789abcdef0", "subnet-0fedcba9876543210"],
    "api_subnets": ["subnet-0aaaa1111bbbb2222", "subnet-0cccc3333dddd4444"]
  }
}
```

### New network

The stack creates a VPC for the nodes and the EKS cluster's API. It builds a public and a private subnet in each of two zones, and `public_nodes` puts the nodes on the public pair. The proxies reach public nodes from their public addresses, which is why `service_ingress_cidrs` holds `0.0.0.0/0`. The NodePort range `30000-32767` is then open to any address.

```
{
  "type": "eks",
  "environment": "/v2/environments/3ps666yxcanq",
  "service": "/v2/services/u91dkrui39cj",
  "name": "production-eks",
  "variables": {
    "region": "us-east-1",
    "public_nodes": true,
    "service_ingress_cidrs": ["0.0.0.0/0"]
  }
}
```

### Post the stack

```
curl -X POST "https://api.webscale.com/v2/stacks" \
  -H "Authorization: Bearer $ACCESS_KEY" \
  -H "Content-Type: application/json" \
  --data @stack.json
```

```
{
  "href": "/v2/stacks/imawpe1lq6lc",
  "name": "production-eks",
  "type": "eks",
  "state": "pending",
  ...
}
```

Note the `href` of the stack.

## 4. Monitor stack provisioning

The **Task monitor** shows the log of the stack as it builds. The first create takes about 20 minutes.

Read the `state` of the stack:

```
curl -s "https://api.webscale.com/v2/stacks/imawpe1lq6lc" \
  -H "Authorization: Bearer $ACCESS_KEY"
```

The `state` runs from `pending` to `synchronizing` to `synchronized`. Repeat the request until it reaches `synchronized`. A `state` of `sync-failed` means the stack stopped, and the log names the reason.

## 5. Deploy to the EKS cluster

The EKS cluster is ready for deployments once the stack reaches `synchronized`. It has the same name as the stack, and the end of the log gives that name as the `kubernetes_cluster_name` output. Enable **Use for Kubernetes** on the AWS provider and enter the name in **Cluster Name**. The provider's region must be the region of the EKS cluster. See [Working with Providers](/docs/how-tos/general/providers/) for more information.

Then create a Kubernetes cluster with a Helm blueprint. See [Kubernetes Clusters](/docs/how-tos/general/kubernetes-clusters/).

## Further reading

- [EKS stack](/hosting-platforms/hosting-v4/stacks/eks/)
- [Kubernetes Clusters](/docs/how-tos/general/kubernetes-clusters/)
- [Create an environment](/hosting-platforms/hosting-v4/how-tos/create-an-environment/)
- [Working with Providers](/docs/how-tos/general/providers/)
- [API documentation](/docs/api/)
---
# Request header value does not match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/request-header-value-does-not-match/
Description: Matches when the value of a specific request header does not match a regular expression.


This condition inspects the value of a specified header sent in the request to determine if it does not match a [regular expression](https://www.regular-expressions.info/). It returns true if the named header contains no values that match the defined pattern.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the name and value comparison. When disabled, the condition performs a case-insensitive match for the header name and evaluates the pattern against all headers sent in the request that match that name.
* **Name**: The exact name of the request header to inspect. This field is required and supports a maximum of 50 characters.
* **Pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the header's value. The condition returns true if the pattern does not match the value of the specified header. This field is required and supports a maximum of 255 characters.

## Measurement

The condition extracts all values for the specified header name from the incoming request and evaluates them against the configured pattern.

* **Match found**: If any instance of the header matches the regular expression, the condition returns false.
* **No match found**: If none of the header values match the pattern, the condition returns true.
* **Missing header**: If the specified header is absent from the request, the condition returns true.
---
# Webscale Pro V3
URL: https://docs.webscale.com/docs/how-tos/deployment/standard/
Description: Deployment guides for Webscale Pro V3 environments.




Webscale Pro V3 runs your application in containers with supporting services managed by Webscale.

Use these guides to:

- Deploy a new Magento or Shopware release
- Run Magento and Shopware CLI commands
---
# Request headers match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/request-headers-match/
Description: Matches when any specified request header names and patterns match.


This condition inspects the incoming request to verify the presence of a specific set of header names and their corresponding values. It returns true if any defined header name is present and contains a value that matches its respective [regular expression](https://www.regular-expressions.info/).

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match for both the header names and the values against the defined patterns.
* **Name**: The exact name of the request header to inspect. Multiple headers can be added to the list.
* **Pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the specific header's value.
* **Defined patterns**: The list of all active name-pattern pairs for this condition. The condition returns true only if the request matches every entry in this list.

## Measurement

The condition resolves the specified headers from the incoming request and evaluates them against the **Defined patterns** as a collective set.

* **Match found**: The condition returns true upon the first match found.
* **No match found**: The condition returns false if no matches are found.
* **Missing header**: The condition returns false if the specified header names are missing from the request.

## Performance

* **Sequential validation**: The system must evaluate each header entry in the list until a result is determined. Processing time increases incrementally with each additional name-pattern pair defined.
* **Short-circuit optimization**: The system stops processing and returns false as soon as a mismatch is identified or a missing header is detected. To minimize processing time, place the headers most likely to be missing or mismatched at the top of the list.
---
# Request headers do not match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/request-headers-do-not-match/
Description: Matches when any specified request header name or pattern is missing or mismatched.


This condition inspects the incoming request to verify if a specific set of header names and their corresponding values is absent. It returns true if any specified header name is missing or if any header value does not match its respective [regular expression](https://www.regular-expressions.info/).

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match for both the header names and the values against the defined patterns.
* **Name**: The exact name of the request header to inspect. Multiple headers can be added to the list.
* **Pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the specific header's value.
* **Defined patterns**: The list of all active name-pattern pairs for this condition. The condition returns true if the request fails to match the entire set defined in this list.

## Measurement

The condition resolves the specified headers from the incoming request and evaluates them against the **Defined patterns** as a collective set.

* **Match found**: If any header value fails to match its defined pattern, the condition returns true.
* **No match found**: The condition returns false only if every header name is present and every corresponding value matches its defined regular expression.
* **Missing header**: If any specified header name is absent from the request, the condition returns true.

## Performance

* **Sequential validation**: The system must evaluate each header entry in the list until a result is determined. Processing time increases incrementally with each additional name-pattern pair defined.
* **Short-circuit optimization**: The system stops processing and returns true as soon as a mismatch is identified or a missing header is detected. To minimize processing time, place the headers most likely to be missing or mismatched at the top of the list.
---
# Request method is
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/request-method-is/
Description: Matches when the request method is one of the selected methods.


This condition inspects the HTTP method of the incoming request and returns true if it matches any of the methods in the selected list.

## Configuration

* **Available request methods**: A list of standard HTTP methods available for selection, including `CONNECT`, `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, `PUT`, and `TRACE`.
* **Selected methods**: The specific methods that trigger the condition. The condition returns true if the request uses any method present in this list.

## Measurement

The condition extracts the method name from the incoming request and performs a lookup against the **Selected methods** list. It returns true as soon as a match is found. If the request method is not in the list, or if the request context is unavailable during evaluation, the condition returns false.
---
# Request method is not
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/request-method-is-not/
Description: Matches when the request method is not one of the selected methods.


This condition inspects the HTTP method of the incoming request and returns true if it does not match any of the methods in the selected list.

## Configuration

* **Available request methods**: A list of standard HTTP methods available for selection, including `CONNECT`, `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, `PUT`, and `TRACE`.
* **Selected methods**: The list of methods that the request must not use for the condition to return true. If a request uses a method present in this list, the condition returns false.

## Measurement

The condition extracts the method name from the incoming request and compares it against the **Selected methods** list. It returns true only if the request method is absent from that list. If the request method is found in the list, or if the request context is unavailable, the condition returns false.
---
# Response headers match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/response-headers-match/
Description: Matches when any specified response header names and patterns match.


This condition inspects the outgoing response to verify the presence of a specific set of header names and their corresponding values. It returns true if any defined header name is present and contains a value that matches its respective [regular expression](https://www.regular-expressions.info/).


{{% alert title="Note:" %}}
This web control condition is only available on Response web controls.
{{% /alert %}}

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match for both the header names and the values against the defined patterns.
* **Name**: The exact name of the response header to inspect. Multiple headers can be added to the list.
* **Pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the specific header's value.
* **Defined patterns**: The list of all active name-pattern pairs for this condition. The condition returns true only if the response matches every entry in this list.

## Measurement

The condition resolves the specified headers from the outgoing response and evaluates them against the **Defined patterns** as a collective set.

* **Match found**: The condition returns true upon the first match found.
* **No match found**: The condition returns false if no matches are found.
* **Missing header**: The condition returns false if the specified header names are missing from the request.

## Performance

* **Sequential validation**: The system must evaluate each header entry in the list until a result is determined. Processing time increases incrementally with each additional name-pattern pair defined.
* **Short-circuit optimization**: The system stops processing and returns false as soon as a mismatch is identified or a missing header is detected. To minimize processing time, place the headers most likely to be missing or mismatched at the top of the list.
---
# Response headers do not match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/response-headers-do-not-match/
Description: Matches when any specified response header name or pattern is missing or mismatched.


This condition inspects the outgoing response to verify if a specific set of header names and their corresponding values is absent. It returns true if any specified header name is missing or if any header value does not match its respective [regular expression](https://www.regular-expressions.info/).

{{% alert title="Note:" %}}
This web control condition is only available on Response web controls.
{{% /alert %}}

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match for both the header names and the values against the defined patterns.
* **Name**: The exact name of the response header to inspect. Multiple headers can be added to the list.
* **Pattern**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the specific header's value.
* **Defined patterns**: The list of all active name-pattern pairs for this condition. The condition returns true if the response fails to match the entire set defined in this list.

## Measurement

The condition resolves the specified headers from the outgoing response and evaluates them against the **Defined patterns** as a collective set.

* **Match found**: If any header value fails to match its defined pattern, the condition returns true.
* **No match found**: The condition returns false only if every header name is present and every corresponding value matches its defined regular expression.
* **Missing header**: If any specified header name is absent from the response, the condition returns true.

## Performance

* **Sequential validation**: The system must evaluate each header entry in the list until a result is determined. Processing time increases incrementally with each additional name-pattern pair defined.
* **Short-circuit optimization**: The system stops processing and returns true as soon as a mismatch is identified or a missing header is detected. To minimize processing time, place the headers most likely to be missing or mismatched at the top of the list.
---
# Status code matches
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/status-code-matches/
Description: Matches when the HTTP response status code matches provided codes or classes.


This condition inspects the HTTP status code returned in the response to determine if it matches a specified value or category. It returns true if the status code matches the codes or shorthand classes defined in the configuration.

{{% alert title="Note:" %}}
This web control condition is only available on Response web controls.
{{% /alert %}}

## Configuration

* **Enter status code(s)**: The values used to evaluate the response status code. This field supports specific codes, shorthand classes, and comma-separated lists.
    * **Specific codes**: Enter the exact three-digit number (e.g., `200`).
    * **Code classes**: Use shorthand notation to match an entire range of codes (e.g., `2xx` matches any 200-level success code).
    * **Multiple entries**: Separate multiple values with a comma (e.g., `200,404,5xx`).

## Measurement

The condition extracts the numerical HTTP status code from the response and converts it into a string representation (e.g., `200` becomes `"200"`). It then evaluates this string against a regular expression pattern generated from your input. The condition returns true only if the status code string matches the pattern.

If the response context is unavailable or missing during evaluation, the condition returns false.
---
# User agent matches
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/user-agent-matches/
Description: Matches when the User-Agent request header matches one or more regular expressions.


This condition inspects the `User-Agent` header of the incoming request to determine if it matches a [regular expression](https://www.regular-expressions.info/). It returns true if the header value satisfies any of the defined patterns.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match against the `User-Agent` string.
* **Enter your pattern(s)**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the `User-Agent` string. Entries should be separated by a new line.
* **Defined patterns**: The list of all active patterns for this condition. The condition returns true if the `User-Agent` header matches any pattern in this list.

## Measurement

The condition extracts the `User-Agent` header from the incoming request and evaluates it against the **Defined patterns**.

* **Match found**: If the header value matches any regular expression in the list, the condition returns true.
* **No match found**: If the header value matches none of the patterns, the condition returns false.
* **Missing header**: If the `User-Agent` header is absent from the request, the condition returns false.

## Performance

* **Sequential validation**: Evaluation time increases incrementally with the number of patterns in the list. For requests that do not match any pattern, the system must evaluate every entry before returning false.
* **Short-circuit optimization**: The condition iterates through the list and returns true as soon as the first match is identified. To minimize processing time, place the most frequently matched patterns at the top of the list.
---
# User agent does not match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/user-agent-does-not-match/
Description: Matches when the User-Agent request header does not match any specified regular expressions.


This condition inspects the `User-Agent` header of the incoming request to determine if it does not match a [regular expression](https://www.regular-expressions.info/). It returns true if the header value does not satisfy any of the defined patterns.

## Configuration

* **Case sensitive**: Whether to enable case sensitivity during the comparison. When disabled, the condition performs a case-insensitive match against the `User-Agent` string.
* **Enter your pattern(s)**: The [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) used to evaluate the `User-Agent` string. Entries should be separated by a new line.
* **Defined patterns**: The list of all active patterns for this condition. The condition returns true only if the `User-Agent` header fails to match every pattern in this list.

## Measurement

The condition extracts the `User-Agent` header from the incoming request and evaluates it against the **Defined patterns**.

* **Match found**: If the header value matches any regular expression in the list, the condition returns false.
* **No match found**: If the header value matches none of the patterns, the condition returns true.
* **Missing header**: If the `User-Agent` header is absent from the request, the condition returns true.

## Performance

* **Sequential validation**: To return true, the system must evaluate the entire list of patterns to ensure no matches exist. Large lists add an incremental processing cost to every request that passes through the filter.
* **Short-circuit optimization**: The system stops processing and returns false as soon as it identifies a match. To optimize performance for traffic that should be excluded, place the patterns most likely to match at the top of the list.
---
# Essentials environment reference
URL: https://docs.webscale.com/docs/reference/essentials-environment-reference/
Description: Reference for services, sudo commands, and helper tools on Webscale Essentials environments.



Lookup-style reference for Essentials environments.

---

## 1. Service management

These services can be managed with `systemctl` (no password) by allowed users:

| Unit                        | Description                |
|-----------------------------|----------------------------|
| `rabbitmq`                  | Message queue              |
| `opensearch`                | Search backend             |
| `valkey-persistent`         | Persistent key-value store |
| `valkey-volatile`           | Volatile cache             |
| `vinyl`                     | Vinyl (Varnish) HTTP Cache |
| `php-fpm`                   | PHP application processes  |
| `mysql`                     | MySQL database             |
| `relay`                     | HTTP relay / reverse proxy |

### Examples

```bash
systemctl status php-fpm
systemctl restart rabbitmq
systemctl restart mysql
```

---

## 2. Helper commands

Available to users in the `adm` group:

- `dev` – run commands in the `php-fpm` container

### Examples

```bash
dev 'php bin/magento --version'
# or
dev 'php bin/console --version'
```

---

## 3. Web root and key paths

- Web root:

  ```bash
  /var/www/html
  ```

- Logs and reports:
  ```bash
  /var/log/{php-fpm,vinyl,opensearch,mysql, ... }
  ```

---

## 4. Queue / cache examples

```bash
# RabbitMQ
rabbitmqctl list_queues

# Valkey
valkey-cli ping
```

If it is password protected:

```bash
valkey-cli -p 6379 -a <volatile-secret> ping
valkey-cli -p 6380 -a <persistent-secret> ping
```

---

## 5. Related how-to guides

- [Deploy a new release](/docs/how-tos/Deployment/Essentials/essentials-deploy/)
- [Magento and Shopware commands](/docs/how-tos/Deployment/Essentials/essentials-commands/)
---
# URL matches
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/url-matches/
Description: Matches when the request URL matches a wildcard pattern or regular expression.


This condition inspects the incoming request URL to determine if it matches the specified criteria. It supports a segmented wildcard interface for common URL structures or a list of regular expressions for complex matching logic.

## Configuration

* **Case sensitive**: Determines if the comparison ignores character casing. When disabled, the system performs a case-insensitive match against all URL components.
* **Use regular expressions**: Whether to enable regular expression matching. When enabled, the input mode switches from segmented wildcard fields to a list of regex patterns.
    * **Disabled**: Provides separate fields for **Scheme**, **Domain**, **Path**, and **Query**.
    * **Enabled**: Provides a list of regex patterns evaluated against the full, normalized, and unescaped unicode URL string.
* **Defined patterns**: The list of URL objects. The condition returns true if the request matches any single entry in this list.

### Wildcard patterns

When **Use regular expressions** is disabled, you define a URL structure using these components:

* **Scheme**: The protocol, such as `http` or `https`. If omitted or set to `*`, both protocols match.
* **Domain**: The requested hostname, such as `www.example.com`. This field supports wildcards like `*.example.com`. If omitted, all domains configured for the application match.
* **Path**: The resource location, such as `/blog/*`. If omitted, all paths match.
* **Query**: The query string parameters, such as `id=*&type=json`. If omitted, all query values match.

## Measurement

The condition evaluates to true if any single entry in the list evaluates to true.

### Wildcard processing

Wildcard matching uses the asterisk (`*`) as a placeholder for any sequence of characters. The system automatically optimizes the underlying regular expression generation for these segments to minimize CPU overhead.

* **Multi-field matching**: All specified fields (Scheme, Domain, Path, and Query) must match simultaneously for that specific object to return true.
* **Omissions**: Any field left blank is treated as an implicit wildcard and is considered an automatic match.

### Regular expression processing

When enabled, the system evaluates the full URL string against the defined patterns.

* **Dialect**: The system uses the [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) dialect.
* **Capture groups**: Capture groups are assigned to variables `$1` through `$9`, which can be substituted in subsequent actions.
* **Assertions**: The system does not add line-begin (`^`) or line-end (`$`) assertions automatically; these must be provided explicitly for exact matching.

## Performance

* **Sequential validation**: Evaluation time increases incrementally with the number of patterns in the list. For requests that do not match any pattern, the system must evaluate every entry before returning false.
* **Short-circuit optimization**: The condition iterates through the list and returns true as soon as the first match is identified. To minimize processing time, place the most frequently matched patterns at the top of the list.
---
# URL does not match
URL: https://docs.webscale.com/docs/reference/web-controls/conditions/url-does-not-match/
Description: Matches when the request URL does not match any configured wildcard pattern or regular expression.


This condition inspects the incoming request URL to determine if it does not match the specified criteria. It supports a segmented wildcard interface for common URL structures or a list of regular expressions for complex matching logic.

## Configuration

* **Case sensitive**: Determines if the comparison ignores character casing. When disabled, the system performs a case-insensitive match against all URL components.
* **Use regular expressions**: Whether to enable regular expression matching. When enabled, the input mode switches from segmented wildcard fields to a list of regex patterns.
    * **Disabled**: Provides separate fields for **Scheme**, **Domain**, **Path**, and **Query**.
    * **Enabled**: Provides a list of regex patterns evaluated against the full, normalized, and unescaped unicode URL string.
* **Defined patterns**: The list of URL objects. The condition returns true only if the request fails to match every single entry in this list.

### Wildcard patterns

When **Use regular expressions** is disabled, you define a URL structure using these components:

* **Scheme**: The protocol, such as `http` or `https`. If omitted or set to `*`, both protocols match.
* **Domain**: The requested hostname, such as `www.example.com`. This field supports wildcards like `*.example.com`. If omitted, all domains configured for the application match.
* **Path**: The resource location, such as `/blog/*`. If omitted, all paths match.
* **Query**: The query string parameters, such as `id=*&type=json`. If omitted, all query values match.

## Measurement

The condition evaluates to true if every single entry in the list evaluates to false.

### Wildcard processing

Wildcard matching uses the asterisk (`*`) as a placeholder for any sequence of characters. The system automatically optimizes the underlying regular expression generation for these segments to minimize CPU overhead.

* **Multi-field matching**: All specified fields (Scheme, Domain, Path, and Query) must match simultaneously for that specific object to be considered a match.
* **Omissions**: Any field left blank is treated as an implicit wildcard and is considered an automatic match.

### Regular expression processing

When enabled, the system evaluates the full URL string against the defined patterns.

* **Dialect**: The system uses the [RE2 regular expression](https://github.com/google/re2/wiki/Syntax) dialect.
* **Capture groups**: Capture groups are assigned to variables `$1` through `$9`, which can be substituted in subsequent actions.
* **Assertions**: The system does not add line-begin (`^`) or line-end (`$`) assertions automatically; these must be provided explicitly for exact matching.

## Performance

* **Sequential validation**: To return true, the system must evaluate the entire list of patterns to ensure no matches exist. Large lists add an incremental processing cost to every request that passes through the filter.
* **Short-circuit optimization**: The system stops processing and returns false as soon as it identifies a match. To optimize performance for traffic that should be excluded, place the patterns most likely to match at the top of the list.
---
# EKS
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/eks/
Description: Guide for understanding and configuring an EKS stack



The EKS stack creates and manages an Amazon Elastic Kubernetes Service (EKS) cluster in your AWS account. Webscale deploys Helm charts to the EKS cluster through the Control Plane. Your own tools, such as `kubectl` or Helm, reach it from the networks you allow. See [Create an EKS stack](/hosting-platforms/hosting-v4/how-tos/create-an-eks-stack/).

An EKS stack consists of:
- An EKS cluster with a private API endpoint inside its VPC and a public one that only the Webscale Control Plane reaches by default
- A fixed-size node group of Arm nodes
- The `vpc-cni`, `kube-proxy`, `coredns`, and `metrics-server` add-ons
- [External Secrets Operator](https://external-secrets.io/) with a ClusterSecretStore for AWS Secrets Manager (enabled by default)
- [Karpenter](https://karpenter.sh/) node autoscaling (enabled by default)
- Supporting infrastructure (subnets and their route tables, a NAT gateway, IAM roles, and the security group rules, plus a VPC in the new network mode)

## Network topology

The stack can be deployed in two modes:

* **Existing network:** Uses the subnets you list in `node_subnets` and `api_subnets` (the stack creates no network). The subnets must already have a route to the internet, or the nodes cannot pull images. Their VPC must have DNS support and DNS hostnames enabled, or the stack update fails. The stack opens the NodePort range to the primary CIDR block of that VPC. Private subnets in the VPC of your dedicated data plane need nothing more, because the proxies already reach the nodes over that VPC's own routing. Connect the two networks yourself when the subnets are in another VPC, and add the network of the proxies to `service_ingress_cidrs`.
* **New network:** Creates a VPC from `network_cidr` with a public and a private subnet in each of two availability zones. The EKS cluster takes all four subnets for its API. The nodes take the private subnets. They reach the internet through one NAT gateway, whose address the `nat_ip` output reports for allowlisting. The proxies have no route to those nodes. Connect the two networks yourself and add the network of the proxies to `service_ingress_cidrs`, or every deployment fails its reachability test. Set `public_nodes` to put the nodes in the public subnets instead. Each node then gets its own public address, the stack creates no NAT gateway, and `nat_ip` is null. `service_ingress_cidrs` needs `0.0.0.0/0`, because the proxies reach the nodes from their public addresses. Ports `30000-32767` are then reachable from any address.

The mode cannot change for the life of the EKS cluster, which cannot move between VPCs. A different mode needs a new stack.

## Data plane

A data plane is a set of Webscale proxies that receive the traffic for your applications, and a dedicated data plane serves your account alone. Its proxies send traffic directly to the EKS cluster's nodes on the node port of the release's Service. Because the port can change with every deployment, the stack opens the whole NodePort range (`30000-32767`) to the network of the proxies. It takes that network from the primary CIDR block of the VPC the nodes are in. `service_ingress_cidrs` opens the range to any other network you name, which is how proxies outside that VPC reach the nodes.

## Variables

{{% alert title="Note:" %}}
The stack `name` becomes the EKS cluster name and prefixes the IAM roles the stack creates. Use 3 to 30 characters from `a-z`, `0-9`, and `-`, starting with a lowercase letter or a digit. Stacks that share an AWS account need unique names.
{{% /alert %}}

| Variable name | Type | Description |
| :--- | :--- | :--- |
| `region` | `string` | *(Required)* **(Permanent)** The AWS region to create the EKS cluster in. |
| `kubernetes_version` | `string` | Kubernetes version of the EKS cluster, its nodes, and its add-ons. Defaults to `"1.36"`. A change upgrades all three. A version past standard support keeps running under EKS extended support, which AWS bills at a higher price. See [Amazon EKS pricing](https://aws.amazon.com/eks/pricing/). |
| `network_cidr` | `string` | **(Permanent)** Network block of the created VPC. Defaults to `10.0.0.0/16`. The stack splits it into a public and a private subnet in each of two availability zones. Provide your own block when the default overlaps a network the EKS cluster must reach. Ignored when `node_subnets` is set. The EKS cluster cannot move between VPCs, and its NAT gateway cannot move between subnets. |
| `node_subnets` | `list(string)` | **(Permanent)** Existing subnet IDs to adopt for the nodes. They must span two or more availability zones and share one VPC with `api_subnets`. When set, the stack creates no network, and `api_subnets` must be set with it. See [Network topology](#network-topology). |
| `api_subnets` | `list(string)` | **(Permanent)** Existing subnet IDs to adopt for the EKS cluster's API. They must span two or more availability zones and share one VPC with `node_subnets`. The EKS cluster places network interfaces in these subnets to reach the nodes, and its private endpoint answers on those interface addresses. Setting one of the two without the other fails the update. See [Network topology](#network-topology). |
| `public_nodes` | `bool` | Whether the nodes launch in the created public subnets instead of the private ones. Defaults to `false`. Ignored when `node_subnets` is set, where the adopted subnets decide the addressing. When `true`, each node carries its own public address and egresses from it, the stack creates no NAT gateway, and `nat_ip` is null. `service_ingress_cidrs` needs `0.0.0.0/0`, because the proxies reach the nodes from those addresses. **Do not change the value on a live EKS cluster.** The change forces a node group migration to the other subnets and removes or adds the NAT gateway. The old nodes can lose their internet access during the migration. |
| `base_instance_type` | `string` | Arm instance type of the base nodes, such as `t4g.large` (default) or `m7g.large`. A change builds a new node group before the stack removes the old one. |
| `base_node_count` | `number` | Node count of the base node group. Defaults to `2`. The group never scales. Karpenter adds temporary nodes on top when enabled. |
| `disk_size` | `number` | Root disk size in GiB of every node. Defaults to `80`. A change builds a new node group before the stack removes the old one. |
| `kubernetes_admins` | `list(string)` | ARNs of IAM roles or users granted cluster admin. Empty by default. See [Cluster access](#cluster-access). |
| `api_ingress_cidrs` | `list(string)` | Networks your API clients reach the public endpoint from, such as your office network or your CI provider's ranges. Defaults to an empty list, so only the Webscale Control Plane reaches it. The public endpoint accepts 40 networks, a limit this list shares with the Control Plane. A change updates the live EKS cluster in place. See [Cluster access](#cluster-access). |
| `service_ingress_cidrs` | `list(string)` | Networks allowed to reach the NodePort range `30000-32767` on the nodes. Defaults to an empty list. The stack already opens the range to the primary CIDR block of the VPC the node subnets are in, and listing that block again fails the stack update. Anything on a listed network reaches every Service the EKS cluster exposes on a node port. See [Data plane](#data-plane). |
| `enable_external_secrets` | `bool` | Whether to install External Secrets Operator and its `aws-secretsmanager` store. Defaults to `true`. When `false`, a chart that declares an ExternalSecret fails to install. Setting it to `false` on a live EKS cluster deletes every ExternalSecret and the Secrets it created. See [Secrets](#secrets). |
| `enable_karpenter` | `bool` | Whether to install Karpenter node autoscaling. Defaults to `true`. When `false`, the EKS cluster stays at `base_node_count` nodes. See [Node autoscaling](#node-autoscaling). |
| `karpenter_cpu_limit` | `number` | Total vCPUs of the temporary nodes Karpenter may add. Defaults to `512`. Karpenter stops adding nodes at the cap. |
| `karpenter_node_lifetime` | `string` | Lifetime of each temporary node, a duration built from `s`, `m`, and `h`. Defaults to `720h`. Karpenter replaces a node at this age, and `Never` disables the rotation. The base node group never expires. |
| `permissions_boundary_arn` | `string` | Optional ARN of a customer-managed permissions boundary policy. See [**AWS Setup**](/hosting-platforms/hosting-v4/aws-setup/). *Not necessary for Webscale managed AWS accounts.*|
| `provisioner_role_name` | `string` | Optional role name to assume for Stack provisioning in the customer account. Defaults to `AccountProvisioner`. See [**AWS Setup**](/hosting-platforms/hosting-v4/aws-setup/). *Not necessary for Webscale managed AWS accounts.* |

### Example:

```
{
  "type": "eks",
  "environment": "/v2/environments/3ps666yxcanq",
  "service": "/v2/services/u91dkrui39cj",
  "name": "production-eks",
  "variables": {
    "region": "us-east-1",
    "node_subnets": ["subnet-0123456789abcdef0", "subnet-0fedcba9876543210"],
    "api_subnets": ["subnet-0aaaa1111bbbb2222", "subnet-0cccc3333dddd4444"],
    "kubernetes_admins": ["arn:aws:iam::123456789012:role/PlatformAdmin"],
    "api_ingress_cidrs": ["203.0.113.0/24"]
  }
}
```

## Outputs

| Output name | Description |
| :--- | :--- |
| `kubernetes_cluster_name` | The name of the EKS cluster. Enter it in **Cluster Name** when you enable **Use for Kubernetes** on the AWS provider. |
| `nat_ip` | Public address of the NAT gateway, the fixed address the nodes use to reach the internet. Null when `node_subnets` is set or `public_nodes` is `true`. |

## Cluster access

The stack grants cluster admin through EKS access entries to the `Webscale` IAM user and to each ARN in `kubernetes_admins`. Webscale creates that user in your account during onboarding. Use `kubernetes_admins` for your own roles and users, and for a provider whose access key belongs to another user. The `Webscale` user and the stack's own IAM roles already have entries, and listing one of them fails the stack update.

An access entry grants permissions, not network access. Only the Webscale Control Plane reaches the public API endpoint until you list your own networks in `api_ingress_cidrs`. A client inside the EKS cluster's VPC reaches the private endpoint instead. `api_ingress_cidrs` does not apply to it, and the cluster security group decides its access.

To deploy through Webscale, enable **Use for Kubernetes** on the AWS provider and enter the `kubernetes_cluster_name` output in **Cluster Name**. Then create a [**Kubernetes cluster**](/docs/how-tos/general/kubernetes-clusters/) with a Helm blueprint. See [**Working with Providers**](/docs/how-tos/general/providers/) for the provider settings.

## Secrets

When `enable_external_secrets` is `true`, the stack installs [External Secrets Operator](https://external-secrets.io/) in the `external-secrets` namespace and a ClusterSecretStore named `aws-secretsmanager` for AWS Secrets Manager. The operator reads each value directly from Secrets Manager, so no value passes through Webscale. It can read only secrets whose names start with `webscale/`. Your chart declares an ExternalSecret that names the secret, and the operator writes a Kubernetes Secret in the namespace of the deployment.

```
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: example
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-secretsmanager
  target:
    name: secret-to-be-created
  dataFrom:
    - extract:
        key: webscale/acme-api/prod
```

Reference the Secret in the container spec of your Deployment with `envFrom`:

```
envFrom:
  - secretRef:
      name: secret-to-be-created
```

Containers read environment variables at start. A rotated value reaches the application on the next deployment.

## Node autoscaling

When `enable_karpenter` is `true`, [Karpenter](https://karpenter.sh/) adds temporary nodes when pods do not fit on the existing nodes and removes them as demand falls. It launches on-demand Arm instances from the `c`, `m`, and `r` families, generation 3 or newer, size `large` or larger. They share the disk size, node role, and security group of the base nodes. `karpenter_cpu_limit` caps the total, and `karpenter_node_lifetime` sets when Karpenter replaces a node.

Karpenter evicts pods when it removes a node and honors a PodDisruptionBudget for up to 20 minutes, then deletes the remaining pods. Add a budget that selects each Deployment's pods.

## Deleting the stack

Delete the Kubernetes clusters that deploy to the EKS cluster before you delete the stack, and wait for Karpenter to remove its temporary nodes. Karpenter launches and terminates those instances itself, so the stack cannot delete them. If temporary nodes are still running, the delete waits for Karpenter to drain them, which can take up to 20 minutes. The stack releases the NAT address when you delete it, and a replacement stack gets a different one. The stack removes only the network pieces it created.
---
# RDS
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/rds/
Description: Guide for understanding and configuring an RDS stack



The RDS stack is an add-on AWS RDS instance or cluster deployed into an existing network.

## Variables

{{% alert title="Note:" %}}
Backend stateful services (like databases) should be isolated from direct internet access on private subnets. Provide the `data_subnets` variable when creating the stack to specify the subnets to deploy into.  See [**Configuration**](/hosting-platforms/hosting-v4/stacks/configuration/) for details.
{{% /alert %}}

| Variable Name | Type | Description |
| :--- | :--- | :--- | :--- |
| `region` | `string` | *(Required)* The region to deploy the RDS cluster - must match the `data_subnets` region. |
| `size` | `string` | *(Required)* Plan size. Must be one of `dev`, `micro`, `mini`, `small`, `medium`, `large`, or `xlarge`. |
| ↳`dev` | | 20 GiB disk, MySQL |
| ↳`micro` | | 20 GiB disk, MySQL |
| ↳`mini` | | 20 GiB disk, MySQL |
| ↳`small` | | 100 GiB disk, MySQL |
| ↳`medium` | | 100 GiB disk, aurora-mysql |
| ↳`large` | | 100 GiB disk, aurora-mysql |
| ↳`xlarge` | | 100 GiB disk, aurora-mysql |
| `data_subnets` | `list(string)` or `string` | *(Required)* Array of subnet IDs [primary, secondary]. May also be a reference to another stack's output. |
| `stacker_variables` | `object` |  Optional configurations for MySQL. |
| ↳`mysql.variant` | `string` | Engine variant (e.g., `mysql`, `aurora-mysql`). Default depends on the plan size. |
| ↳`mysql.version` | `string` | `"8.0"` / `"8.0.mysql_aurora.3.06.0"` | Engine version override. Defaults to `"8.0"` for the `mysql` variant and `"8.0.mysql_aurora.3.06.0"` for the `aurora-mysql` variant. |
| ↳`mysql.snapshot_identifier` | `string` | Snapshot identifier to restore the database from. |

### Example:

```
{
  "type": "rds",
  "environment": "/v2/environments/tu8aovkn7waj",
  "service": "/v2/services/2tpkjj7e0b28",
  "name": "RDS",
  "variables": {
    "size": "medium",
    "region": "us-east-1",
    "data_subnets": "/v2/stacks/4d4d1d4koe12/outputs/data_subnets"
    "stacker_variables":{
      "mysql": {
        "snapshot_identifier": "arn:aws:rds:us-east-1:123456789012:cluster-snapshot:my-snapshot-08242026"
      }
    }
  }
}
```

## Outputs

| Output name | Description |
| :--- | :--- |
| `db_endpoint` | The connection endpoint for the RDS database. |
| `db_password_secret_name` | The name of the Secrets Manager secret containing the RDS password. |
---
# Agentic Commerce OS
URL: https://docs.webscale.com/docs/agentic-commerce-os/


---
# Components
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/components/
Description: Components that make up a V4 stack



## Data volume

To ensure data durability and architectural flexibility, all application file
data in the V4 platform is allocated separately from the compute layer and
stored on an independent, persistent cloud data volume.

Because this data volume exists independently of the core server instance, the
compute layer can be destroyed, upgraded, or reconfigured without any risk to
the underlying data.

In single-server configurations, this volume acts as the local storage for the
application's stateful files. As you scale to multi-server tiers (Standard, Pro,
HA Pro), this same volume serves as a centralized file database, exported
via an NFS shared filesystem to feed the horizontally autoscaling web nodes.

Snapshots of the data volume are performed at least daily and serve as a point
of recovery against unintended software behaviors, human error, or malicious
activity.

## Core server

At the heart of the Webscale V4 platform is the core server, a highly optimized,
multi-purpose environment configured to handle the entire application ecosystem
out of the box. Its role adapts dynamically depending on the architectural tier
in use, shifting from an all-in-one host to a specialized backend manager as
a stack scales.

**Essentials**: The core server is the entire environment. It functions as a
single-tenant node hosting every layer of your stack: serving the web
application code, handling cron jobs, and running critical infrastructure
components like MySQL/MariaDB, Valkey, RabbitMQ, and OpenSearch on a localized,
high-performance filesystem.

**Scaling Upward**: As workloads grow and you transition to higher tiers, the
core server is systematically offloaded to maximize efficiency and resilience:

* **Standard**: It hands off the web delivery layer to a dedicated,
horizontally autoscaling web tier, retaining responsibility for the database,
caching, queueing, and file layers.

* **Pro** and **HA Pro**: Critical infrastructure services (databases, caches,
and search services) are migrated to cloud-native managed services. The core
server still provides message queueing, data volume sharing, and central cron
execution.

Regardless of tier, the [**dev**](/hosting-platforms/hosting-v4/commands/dev/)
command provides consistent access to a shell in an application container
environment. Shared directories and files are configured in the `shared` stack
attribute, and they are automatically mounted into the container at execution
time.

## Web servers

In scaling tiers (Standard and above), the web delivery layer is decoupled from
backend services and managed as a dynamic, horizontally autoscaling cluster.

Application code is provided to a scaling cluster by creating a custom container
image and configuring the cluster to run it. Shared directories and files are
configured in the `shared` stack attribute, and they are automatically mounted
into the container at execution time.

The configuration of the scaling cluster is managed at the Webscale control
plane. [CodeDirect](/docs/how-tos/codedirect/) is recommended to build and
auto deploy new images to a stack.

## Cloud native services

For the **Pro** and **HA Pro** tiers, the most critical services are offloaded
to managed, cloud-native services. This provides dedicated resources, separate
backups, and enhanced recoverability, while allowing backend components to scale
independently and significantly reducing routine maintenance overhead.
---
# Essentials V4 Architecture Overview
URL: https://docs.webscale.com/docs/reference/plans/essentials-v4-overview/
Description: A Brief Overview of the Essentials V4 Architecture



Webscale Essentials V4 is a next-generation e-commerce hosting environment built on a **Decoupled Plane Architecture**. By utilizing a "Three-Plane" model, we separate administrative overhead and security processing from your core storefront, ensuring that your customer experience remains fast and resilient.

{{< figure src="essentials-v4.png" caption="Essentials V4 architecture">}}

---

## **1\. The Design Philosophy**

### **Decoupling for Performance**

In traditional hosting, the "Control" of the server (backups, logging, analytics) happens on the same resources as the "Traffic." If your logs grow too fast or a backup kicks off during a sale, your site slows down.

* **The Essentials V4 Advantage:** We move the "Brain" of the site to a dedicated **Control Plane**. This ensures that even under heavy management tasks, your **Data Plane** (the storefront) has 100% of its resources dedicated to serving customers.

### **Daemonless Container Security**

V4 utilizes **Podman** for container orchestration. This means every service from Magento to MySQL runs as an isolated, rootless process. If one container needs a restart, it doesn't affect the others, providing a higher level of security and "Self-Healing" stability.

---

## **2\. Traffic Flow & The AWS Foundation**

*This section **Explains** how we utilize AWS services to deliver your site.*

1. **The Edge (AWS Route 53 & CloudFront):** Traffic is first routed via **AWS Route 53** to the **Webscale CDN (CloudFront)**. This ensures that static assets are served from the global location closest to your customer.
2. **The Perimeter (Webscale Data Plane):** Before reaching your server, requests are scrubbed by the Webscale. This  prevents malicious traffic from ever impacting the performance of your site.
3. **The Core (AWS EC2 & VPC):** Your application resides within a secure **AWS VPC**. The storefront and its persistent services (Database, Redis, etc.) are hosted on high-performance **AWS EC2** instance, orchestrated by Podman to ensure maximum efficiency.

---

## **3\. The Essentials V4 Baseline**

*This **Reference** table serves as the technical source of truth for the V4 stack.*

| Component | Technology | AWS Service utilized | Deployment Location |
| :---- | :---- | :---- | :---- |
| **DNS** | Webscale Managed | **AWS Route 53** | Global Edge |
| **Edge Delivery** | Webscale CDN | **AWS CloudFront** | Global Edge |
| **Security** | WAF & DDoS Protection  | **Webscale Data Plane** | Perimeter Filter |
| **Compute** | Proxy & App Layer | **AWS EC2** | Shared & Dedicated |
| **Orchestration** | Podman | **Linux Runtime \- PHP\_FPM Caching (Edge) \- Vinyl (Varnish Caching (Data) \- Redis (Tri-Partitioned) Database \- MySQL / MariaDB Search \- Opensearch** | Daemonless Container |
| **Storage** | Persistent Media | **AWS EBS / EFS** | Persistent Volume |
| **Backups** | 7 day snapshot |  |  |
| **SSH** | SSH Connect / SSH Gateway |  |  |
---
# Hosting V4
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/
Description: V4 is Webscale’s fourth-generation hosting platform, combining battle-tested
architectures and systems engineering patterns with improved security,
performance, cost-management, and re-configurability — all accessible from the
Webscale Control Plane.


# Primary stacks

To accommodate a wide range of application needs, traffic patterns, and
reliability requirements, the V4 platform is built around four distinct
architectural stacks. Whether hosting Magento, Shopware, WordPress, or custom PHP
and Node.js applications, these stacks provide a clear upgrade path as traffic
and complexity grow.

## Essentials

The Essentials stack provides a robust, streamlined foundation for applications
that do not yet require horizontal scaling. It provisions a comprehensive,
all-in-one environment on a single, highly optimized server.

**Architecture**: Single-server deployment.

**How it Works**: A single server accommodates the complete application stack,
including the web tier, an NFS shared filesystem, cron execution, relational
database (MySQL or MariaDB), caching (Valkey), message brokering (RabbitMQ), and
search (OpenSearch).

**Best For**: Baseline workloads, staging environments, or applications with
predictable, moderate traffic.

## Standard

The Standard stack introduces dynamic capacity by decoupling the web delivery
layer from the backend services.

**Architecture**: An autoscaling web tier supported by a single "core" server.

**How it Works**: The web server is moved into a horizontally scaling layer that
automatically expands or contracts based on real-time request demand. The core
server processes and manages common backend services (databases, caching,
search, NFS, and cron).

**Best For**: Applications prone to traffic spikes or those experiencing rapid
growth that require immediate, automated scaling at the web tier.

## Pro

The Pro stack optimizes performance and reduces management overhead by offloading
critical backend services to highly resilient, cloud-native managed services.

**Architecture**: Autoscaling web tier + cloud provider managed services + core
server.

**How it Works**: Building on the Standard stack, Pro moves heavy-lifting
services off the core server and into the cloud provider's ecosystem. For
example, MySQL is managed via AWS RDS, Valkey is transitioned to ElastiCache,
and OpenSearch utilizes the AWS OpenSearch service. The core server remains
strictly for shared files (NFS), cron execution, and message queueing.

**Best For**: Resource-intensive applications that benefit from the dedicated
performance, separate backups, and reduced operational overhead of managed
cloud services.

## Pro HA

The Pro HA (High Availability) stack is the pinnacle of the V4 architecture,
designed for mission-critical applications where uptime is the ultimate
priority.

**Architecture**: Multi-zone deployment of the Pro stack with automatic failover.

**How it Works**: HA Pro takes the distributed architecture of the Pro stack and
spans it across two isolated availability zones. By redundantly defining most
components across these zones, the platform provides seamless, automatic
failover in the event of a total zone failure.

**Best For**: Enterprise-grade workloads and revenue-critical applications that
require strict Service Level Agreements (SLAs) and maximum fault tolerance.

# Additional stacks

To provide further flexibility and adaptability, the primary stacks can be combined with additional infrastructure using add-on stacks. These stacks can be configured as standalone or seamlessly interconnected to other architectural components.

## EKS stack

The EKS stack creates and manages an Amazon EKS cluster in your AWS account. The stack also builds the add-ons, a base node group, External Secrets Operator, Karpenter node autoscaling, and a network unless you bring subnets. Webscale deploys Helm charts to the cluster through the Control Plane. Explore [**this guide**](/hosting-platforms/hosting-v4/stacks/eks/) for network topologies, variables, outputs, cluster access, secrets, and autoscaling.

## RDS stack
The RDS stack is an add-on AWS RDS instance or cluster deployed into an existing network. Explore [**this guide**](/hosting-platforms/hosting-v4/stacks/rds/) for details.

## Web server stack

The Web server stack is a language-agnostic environment designed for hosting web-facing containerized applications. By decoupling routing from application runtimes, it allows developers to deploy custom container images while Webscale manages underlying auto-scaling, network topology, and security. The stack supports both standalone VPC deployments and add-on integrations into existing subnets, utilizing host-level Go Relay proxying to dynamically forward HTTP/HTTPS traffic to isolated containers. Explore [**this guide**](/hosting-platforms/hosting-v4/stacks/web-server/) to learn about network topologies, cluster metadata configuration, custom port overrides, and traffic architecture.
---
# Web server
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/web-server/
Description: Guide for understanding and configuring a Web server stack



The Web server stack is a language-agnostic container-hosting environment intended for serving web-facing containerized applications. Developers bring their own container image and seamlessly injects it into the Webscale hosting platform.

A Web server stack consists of:
 - Webscale Application
 - Webscale scaling cluster
 - Supporting infrastructure (VPC, routing tables, security group, etc.)

## Network Topology

The stack can be deployed in two modes:

* **Standalone**: Automatically provisions its own complete network tier, including VPC, Internet Gateway, and public routing tables.
* **Add-On**: Seamlessly creates the auto-scaling web cluster in the existing infrastructure's public subnets. When creating the web server stack, if an array of public subnets are provided, the web server will use the existing networking infrastructure and act as an add-on. See [**Configuration**](/hosting-platforms/hosting-v4/stacks/configuration/) for details.

## Variables

| Variable name | Type | Description |
| :--- | :--- | :--- |
| `size` | `string` | *(Required)* Plan size. Must be one of "dev", "small", "medium", "large", or "xlarge". |
| `region` | `string`  | *(Required)* The region to deploy the stack resources. |
| `public_subnets` |  `list(string)` or `string` | Array of subnet IDs [primary, secondary]. May also be a reference to another stack's output. If provided, the cluster will deploy into the existing network. |
| `stacker_variables` | `object` | Optional configuration variables. |
| ↳ `share` | `list(string)` | A list of specific subdirectory paths within the host's file system to bind-mount into the application container's web root. Example: `["html/app/etc/env.php","html/pub/media","html/var"]`|

### Example:

```
{
  "type": "web-server",
  "environment": "/v2/environments/tu8aovkn7waj",
  "service": "/v2/services/2tpkjj7e0b28",
  "name": "PWA Frontend",
  "variables": {
    "size": "medium",
    "region": "us-east-1",
    "public_subnets": "/v2/stacks/4d4d1d4koe12/outputs/public_subnets"
  }
}
```

## Cluster Metadata Variables

Cluster metadata is used to configure container runtime variables. The following keys dictate how the container environment is constructed:

| Metadata Key | Default | Description |
| :--- | :--- | :--- |
| `CONTAINER_IMAGE_URI` |  | *(Required)* The URI of the container image to pull and run. |
| `CONTAINER_HTTP_PORT` | `3000` | The internal port your containerized application listens on. |
| `CONTAINER_ENVIRONMENT` | | A space-separated list of environment variables to forward into the container environment. Any variables specified here must also be defined as keys in the cluster metadata. |
---
# Essentials v4 Plan Specifications
URL: https://docs.webscale.com/docs/reference/plans/essentials-v4-specifications/
Description: A reference for Essentials v4 plan specifications


**Purpose:** This page lists resource and feature specifications for Webscale Essentials v4 plans (S, M, L, XL).

### **Architecture overview**

* All Essentials tiers operate under a **single-server architecture**.
* **Infrastructure remains constant; resource allocation scales** between S, M, L, and XL.

### **Plan comparison**

The table below summarizes resource and major feature allocations across Essentials tiers.

| Feature | Specification | S | M | L | XL |
| ----- | ----- | :---: | :---: | :---: | :---: |
| **Proxy Service** | Webscale Dataplane | Shared | Shared | Shared | Shared |
| **Cloud Hosting** | Managed AWS EC2 | ✓ | ✓ | ✓ | ✓ |
| **Compute** | vCPU | 8 | 16 | 16 | 32 |
| **Memory** | RAM (GB) | 32 | 32 | 64 | 64 |
| **Storage** | EBS (GB) | 140 | 140 | 140 | 140 |
| **Backups** | Daily Backup Retention (days) | 7 | 7 | 7 | 7 |
| **CDN** | Amazon CloudFront | ✓ | ✓ | ✓ | ✓ |
|  | Data Transfer Egress (GB) | 50 | 50 | 50 | 50 |
| **Security** | Web Application Firewall | Basic | Basic | Basic | Basic |
|  | Origin Protection (App Shield) | Level 1 | Level 1 | Level 1 | Level 1 |
| **Performance** | Dynamic Site Cache (GB) | 1 | 1 | 1 | 1 |
|  | Image Optimization | 20K/mo | 20K/mo | 20K/mo | 20K/mo |
| **Observability** | Traffic Viewer | ✓ | ✓ | ✓ | ✓ |
|  | Traffic Viewer Retention | 1 Day | 1 Day | 1 Day | 1 Day |
|  | Monitoring & Alerts | ✓ | ✓ | ✓ | ✓ |

*Notes:*

* “Shared” in **Proxy Service** indicates all Essentials tiers operate on a shared Webscale dataplane.
* Check your commercial terms for any overage, regional, or billing specifics not captured here.

---

### **Features included in all Essentials plans**

The following capabilities are available **across all Essentials tiers** (S, M, L, XL).

#### **Application delivery**

Webscale operates directly in the traffic path for all Essentials plans.

Includes:

* Global CDN
* Dynamic Site caching
* Web Application Firewall
* Traffic Viewer
* Real-time image optimization

#### **Cloud hosting & operations**

All Essentials plans include:

* AWS-based architecture
* Commerce-tuned configurations
* Infrastructure patching and updates
* Monitoring and alerting
* Incident response
* Operational ownership by Webscale

#### **Platform compatibility**

Essentials supports the following commerce platforms:

* Magento
* Adobe Commerce
* Shopware
* WooCommerce
---
# Standard V4 Architecture Overview
URL: https://docs.webscale.com/docs/reference/plans/standard-v4-overview/
Description: A Brief Overview of the Standard V4 Architecture



Webscale Standard V4 is a next-generation e-commerce hosting environment built on a **Decoupled Plane Architecture**. By utilizing a "Three-Plane" model, we separate administrative overhead and security processing from your core storefront, ensuring that your customer experience remains fast and resilient.

![](standard_v4.png)

---

## **1\. The Design Philosophy**

### **Decoupling for Performance**

In traditional hosting, the "Control" of the server (backups, logging, analytics) happens on the same resources as the "Traffic." If your logs grow too fast or a backup kicks off during a sale, your site slows down.

* **The Standard V4 Advantage:** We move the "Brain" of the site to a dedicated **Control Plane**. This ensures that even under heavy management tasks, your **Data Plane** (the storefront) has 100% of its resources dedicated to serving customers.

### **Daemonless Container Security**

V4 utilizes **Podman** for container orchestration. This means every service from Magento to MySQL runs as an isolated, rootless process. If one container needs a restart, it doesn't affect the others, providing a higher level of security and "Self-Healing" stability.

---

## **2\. Traffic Flow & The AWS Foundation**

*This section **Explains** how we utilize AWS services to deliver your site.*

1. **The Edge (AWS Route 53 & CloudFront):** Traffic is first routed via **AWS Route 53** to the **Webscale CDN (CloudFront)**. This ensures that static assets are served from the global location closest to your customer.
2. **The Perimeter (Webscale Data Plane):** Before reaching your server, requests are scrubbed by the Webscale. This  prevents malicious traffic from ever impacting the performance of your site.
3. **The Core (AWS EC2 & VPC):** Your application resides within a secure **AWS VPC**. The application is hosted on a pre-defined managed cluster of autoscaling **AWS EC2** instances that use Podman containers. The optional admin cluster also resides on an **AWS EC2** instance and is independent of the application managed cluster. The storefront and its persistent services (Database, Redis, etc.) are hosted on high-performance **AWS EC2** instance, orchestrated by Podman to ensure maximum efficiency.

---

## **3\. The Standard V4 Baseline**

*This **Reference** table serves as the technical source of truth for the V4 stack.*

| Component | Technology | AWS Service utilized | Deployment Location |
| :---- | :---- | :---- | :---- |
| **DNS** | Webscale Managed | **AWS Route 53** | Global Edge |
| **Edge Delivery** | Webscale CDN | **AWS CloudFront** | Global Edge |
| **Security** | WAF & DDoS Protection  | **Webscale Data Plane** | Perimeter Filter |
| **Compute** | Proxy & App Layer | **AWS EC2** | Shared & Dedicated |
| **Orchestration** | Podman | **Linux Runtime \- PHP\_FPM Caching (Edge) \- Vinyl (Varnish Caching (Data) \- Redis (Tri-Partitioned) Database \- MySQL / MariaDB Search \- Opensearch** | Daemonless Container |
| **Storage** | Persistent Media | **AWS EBS / EFS** | Persistent Volume |
| **Backups** | 7 day snapshot |  |  |
| **SSH** | SSH Connect / SSH Gateway |  |  |
---
# Standard v4 Plan Specifications
URL: https://docs.webscale.com/docs/reference/plans/standard-v4-specifications/
Description: A reference for Standard v4 plan specifications


**Purpose:** This page lists resource and feature specifications for Webscale Standard v4 plans (Small, Medium, Large, X-Large).

---

**Architecture overview**

* Standard v4 is built on a **Decoupled Plane Architecture** — a three-plane model that separates administrative overhead and security processing from the core storefront.
* The **Control Plane** handles management tasks (backups, logging, analytics), freeing the **Data Plane** to dedicate 100% of its resources to serving customers.
* Container orchestration uses **Podman**, so every service runs as an isolated, rootless process — providing self-healing stability without cross-service impact.
* Unlike Essentials, Standard v4 uses a **split Data Server / App Cluster model** — the data server and application cluster are separate, dedicated instances that scale independently.

---

**Plan comparison**

The table below summarizes resource and major feature allocations across Standard v4 tiers.

**Data Server**

| Feature | Specification | Small | Medium | Large | X-Large |
| ----- | :---: | :---: | :---: | :---: | :---: |
| Proxy Service | Webscale Dataplane | Shared | Shared | Shared | Shared |
| Cloud Hosting | Managed AWS EC2 | ✓ | ✓ | ✓ | ✓ |
| Compute | vCPU | 8 | 16 | 16 | 32 |
| Memory | RAM (GB) | 32 | 32 | 64 | 64 |
| Storage | EBS (GB) | 40 / 100 | 40 / 100 | 40 / 100 | 40 / 100 |
| Backups | Daily Backup Retention (days) | 7 | 15 | 15 | 15 |

**App Cluster**

| Feature | Specification | Small | Medium | Large |
| ----- | :---: | :---: | :---: | :---: |
| Compute | vCPU | 2 | 4 | 8 |
| Memory | RAM (GB) | 4 | 8 | 16 |
| App Cluster Min | Instances | 1 | 1 | 1 |
| App Cluster Max | Instances | 4 | 4 | 4 |

*Notes:*

* App Cluster and Data Server resource allocations can be purchased as listed in the sizing table or modified as needed to meet requirements.
* "Shared" in Proxy Service indicates all Standard v4 tiers operate on a shared Webscale dataplane.
* EBS storage is listed as 40 Gb boot / 100 Gb data volumes.
* Check your commercial terms for any overage, regional, or billing specifics not captured here.

---

**Features included in all Standard v4 plans**

The following capabilities are available across all Standard v4 tiers (Small, Medium, Large, X-Large).

**Application delivery**

Webscale operates directly in the traffic path for all Standard v4 plans.

Includes:

* Global CDN (AWS CloudFront)
* Web Application Firewall configurable via Web Controls
* Traffic Viewer
* Image optimization
* DDoS protection

**Cloud hosting & operations**

All Standard v4 plans include:

* AWS-based architecture (EC2, EBS, VPC, Route 53\)
* Dedicated data server separate from the application cluster
* Autoscaling application cluster (production tiers)
* Podman-based daemonless container orchestration
* Commerce-tuned configurations (PHP-FPM, Varnish, Redis, OpenSearch, MySQL/MariaDB)
* Infrastructure patching and updates
* Monitoring and alerting
* Incident response
* SSH Connect / SSH Gateway access
* Operational ownership by Webscale

**Platform compatibility**

Standard v4 supports the following commerce platforms:

* Magento
* Adobe Commerce
* Shopware
* WooCommerce
---
# Pro V4 Architecture Overview
URL: https://docs.webscale.com/docs/reference/plans/pro-v4-overview/
Description: A Brief Overview of the Pro V4 Architecture



Webscale Pro V4 is a next-generation e-commerce hosting environment built on a **Decoupled Plane Architecture**. By utilizing a "Three-Plane" model, we separate administrative overhead and security processing from your core storefront, ensuring that your customer experience remains fast and resilient.

![](pro_v4.png)

---

## **1\. The Design Philosophy**

### **Decoupling for Performance**

In traditional hosting, the "Control" of the server (backups, logging, analytics) happens on the same resources as the "Traffic." If your logs grow too fast or a backup kicks off during a sale, your site slows down.

* **The Pro V4 Advantage:** We move the "Brain" of the site to a dedicated **Control Plane**. This ensures that even under heavy management tasks, your **Data Plane** (the storefront) has 100% of its resources dedicated to serving customers.

### **Daemonless Container Security**

V4 utilizes **Podman** for container orchestration. This means specific services from Magento to runs as an isolated, rootless process. If one container needs a restart, it doesn't affect the others, providing a higher level of security and "Self-Healing" stability.

---

## **2\. Traffic Flow & The AWS Foundation**

*This section **Explains** how we utilize AWS services to deliver your site.*

1. **The Edge (AWS Route 53 & CloudFront):** Traffic is first routed via **AWS Route 53** to the **Webscale CDN (CloudFront)**. This ensures that static assets are served from the global location closest to your customer.
2. **The Perimeter (Webscale Data Plane):** Before reaching your server, requests are scrubbed by the Webscale. This  prevents malicious traffic from ever impacting the performance of your site.
3. **The Core (AWS Services):** Your application resides within a secure **AWS VPC**. The application is hosted on a pre-defined managed cluster of autoscaling **AWS EC2** instances that use Podman containers. The optional admin cluster also resides on an **AWS EC2** instance and is independent of the application managed cluster. The storefront and its persistent services (Rabbit MQ, Cron, NFS, and Valkey) are hosted on high-performance **AWS EC2** instance, orchestrated by Podman to ensure maximum efficiency. Opensearch resides on the **AWS Opensearch AWS** service . MYSQL resides on **AWS RDS Aurora** service.

---

## **3\. The Pro V4 Baseline**

*This **Reference** table serves as the technical source of truth for the V4 stack.*

| Component | Technology | AWS Service utilized | Deployment Location |
| :---- | :---- | :---- | :---- |
| **DNS** | Webscale Managed | **AWS Route 53** | Global Edge |
| **Edge Delivery** | Webscale CDN | **AWS CloudFront** | Global Edge |
| **Security** | WAF & DDoS Protection  | **Webscale Data Plane** | Perimeter Filter |
| **Compute** | Proxy & App Layer | **AWS EC2** | Shared & Dedicated |
| **Orchestration** | Podman | **Linux Runtime \- PHP\_FPM Caching (Edge) \- Vinyl (Varnish Caching (Data) \- Redis (Tri-Partitioned)** | Daemonless Container |
| **Search** | **Opensearch** | AWS Opensearch | Shared & Dedicated |
| **Cache** | **Redis/Valkey** | AWS Elasticache | Shared & Dedicated |
| **Database** | **MYSQL** | AWS RDS Aurora | Shared & Dedicated |
| **Storage** | Persistent Media | **AWS EBS / EFS** | Persistent Volume |
| **Backups** | 7 day snapshot |  |  |
| **SSH** | SSH Connect / SSH Gateway |  |  |
---
# Pro V4 HA Architecture Overview
URL: https://docs.webscale.com/docs/reference/plans/pro-v4-ha-overview/
Description: A Brief Overview of the Pro V4 HA Architecture


Webscale Pro V4 HA is a next-generation e-commerce hosting environment built on a **Decoupled Plane Architecture**. By utilizing a "Three-Plane" model, we separate administrative overhead and security processing from your core storefront, ensuring that your customer experience remains fast and resilient across multiple Availability Zones.

![Pro V4 HA Architecture Diagram](ha_pro_v4.png)

## 1. The Design Philosophy

### Decoupling for Performance

In traditional hosting, the "Control" of the server (backups, logging, analytics) happens on the same resources as the "Traffic." If your logs grow too fast or a backup kicks off during a sale, your site slows down.

* **The Pro V4 HA Advantage:** We move the "Brain" of the site to a dedicated **Control Plane**. This ensures that even under heavy management tasks, your **Data Plane** (the storefront) has 100% of its resources dedicated to serving customers.

### Daemonless Container Security

V4 utilizes **Podman** for container orchestration. This means specific services from Magento to runs as an isolated, rootless process. If one container needs a restart, it doesn't affect the others, providing a higher level of security and "Self-Healing" stability.

## 2. Traffic Flow & The AWS Foundation

This section *Explains* how we utilize AWS services to deliver your site.

1. **The Edge (AWS Route 53 & CloudFront):** Traffic is first routed via **AWS Route 53** to the **Webscale CDN (CloudFront)**. This ensures that static assets are served from the global location closest to your customer.
2. **The Perimeter (Webscale Data Plane):** Before reaching your server, requests are scrubbed by the Webscale. This prevents malicious traffic from ever impacting the performance of your site.
3. **The Core (AWS Services):** Your application resides within a secure **AWS VPC** that spans **two Availability Zones**. The application is hosted on a pre-defined managed cluster of autoscaling **AWS EC2** instances that use Podman containers in each Availability Zone. The storefront and its persistent services (Rabbit MQ, Cron, NFS, and Valkey) are hosted on high-performance **AWS EC2** instance, orchestrated by Podman to ensure maximum efficiency. Opensearch resides on the **AWS Opensearch AWS** service. MYSQL resides on **AWS RDS Aurora** service. All persistence layer services are replicated across both Availability Zones for high availability.

## 3. The Pro V4 HA Baseline

This *Reference* table serves as the technical source of truth for the V4 HA stack.

| Component | Technology | AWS Service utilized | Deployment Location |
|-----------|-----------|---------------------|---------------------|
| **DNS** | Webscale Managed | AWS Route 53 | Global Edge |
| **Edge Delivery** | Webscale CDN | AWS CloudFront | Global Edge |
| **Security** | WAF & DDoS Protection | Webscale Data Plane | Perimeter Filter |
| **Compute** | Proxy & App Layer | AWS EC2 | Shared & Dedicated (Multi-AZ) |
| **Orchestration** | Podman | Linux Runtime - PHP_FPM Caching (Edge) - Vinyl (Varnish Caching (Data)) - Redis (Tri-Partitioned) | Daemonless Container |
| **Search** | Opensearch | AWS Opensearch | Shared & Dedicated (Multi-AZ) |
| **Cache** | Redis/Valkey | AWS Elasticache | Shared & Dedicated (Multi-AZ) |
| **Database** | MYSQL | AWS RDS Aurora | Shared & Dedicated (Multi-AZ) |
| **Storage** | Persistent Media | AWS EBS / EFS | Persistent Volume (Multi-AZ) |
| **Backups** | 7 day snapshot | | |
| **SSH** | SSH Connect / SSH Gateway | | |
---
# Access
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/access/
Description: Accessing servers in a V4 environment


Whether you are a system administrator making configuration changes, an engineer
actively debugging a node, or maintaining a CI/CD pipeline deploying code, the
V4 platform provides secure, role-specific pathways for accessing your servers
and the Webscale Control Plane.

## Interactive User Access

For direct shell access to a target server, utilize either [SSH
Connect](/docs/how-tos/ssh-connect/) or the [SSH
Gateway](/docs/how-tos/ssh-gateway/).

When you authenticate and drop into a shell, your user session is automatically
assigned to the `dev` group. Membership in this group grants access to run
commands to maintain the environment and to update files in the `/var/www`
directory.

To safely manage application files on the host, you must use the `/shadow/www`
directory. This directory acts as an intelligent proxy to the actual web root
(`/var/www`). By making your edits, uploads, and file manipulations within
`/shadow/www`, the system ensures that the underlying ownership of all files is
automatically and correctly maintained as `www-data:www-data`.

Important: You must always use `/shadow/www` for file manipulations. Writing
directly to `/var/www` will bypass the proxy layer and result in incorrect file
ownership, which can cause application errors and permission denials at runtime.

## Automated and API Access

For automated workflows, such as CI/CD pipelines deploying code, or scripts
interacting with the Control Plane API, access should always be routed through a
[Service User](/docs/how-tos/general/service-users/).

Creating a dedicated service user allows you to:

* Enforce least privilege: Service users can be strictly scoped, granting them
  only the exact permissions required by the automation and nothing more.
* Decouple access life-cycles: Tying automation to a specific human user is a
  fragile operational pattern. If that employee leaves the organization or their
  access is deactivated, any automated systems relying on their credentials will
  instantly fail. Service users exist independently of human personnel, ensuring
  your pipelines and scripts remain continuously operational.
---
# Configuration
URL: https://docs.webscale.com/hosting-platforms/hosting-v3/configuration/
Description: Explanation of how V3 environments are configured.



Initial configuration and setup of a V3 servers of most types are handled
primarily through a program called `invoker`. Permanent servers, such as
NFS servers, bastions, or other accessory servers, are maintained by request
to Webscale support following their initial creation. Cluster-based servers,
such as web servers, cron servers, consumer servers, or other servers based
on the `web-server` image family are expected to only be configured and
maintained through their initial configuration. This is due to their transient
nature.

### Invoker configuration

For invoker to run successfully, it needs three pieces of configuration:

1. Bootstrap sequence locator
2. Customer name
3. Environment name

The primary configuration for invoker is called the "bootstrap sequence". It is
a sequence of commands retrieved at server startup from an locator that usually
specifies an S3 bucket. For most of the history of invoker, the only way to
specify a bootstrap locator was to provide the file
`/opt/webscale/invoker/etc/invoker-service-boot.cmd` with a "locator". A locator
is a URL-like string specifying the location of a resource. Most bootstrap
locators are of the form:
s3:_region_:_customer_-_environment_-config:/bootstrap.cmd. There are multiple
ways to populate the file for invoker, but the most typical way is to write it
using a cloud-init shell script in an AWS launch template specified by a cluster
that creates servers.

Customer and environment names which allow it to log its activity to
CloudWatch in most AWS-based environments. Similarly to the bootstrap sequence,
these are usually written by a cloud-init script in a launch template to
the file `/opt/webscale/invoker/etc/invoker-service.conf`.

However, beginning in [release 2026.36](/docs/reference/images/2026.36/) of
the web server image, invoker can be configured entirely from its cluster
metadata, by providing values for following keys. This allows for the
elimination of a cloud-init script entirely.

| Key  | Description |
|----------------------|-----------------------------------------------------|
| CONTAINER_IMAGE_URI  | When a cluster is configured to refer to a container image, this key is automatically set. |
| WEBSCALE_BOOTSTRAP   | Invoker locator to find bootstrap sequence. For example: `s3:us-east-1:customer-env-config:/bootstrap.cmd` |
| WEBSCALE_CUSTOMER    | Customer name used for setting up CloudWatch logging |
| WEBSCALE_ENVIRONMENT | Environment name used for setting up CloudWatch logging |
| WEBSCALE_SHARE       | Specifies the root of a shared file system. For example: `/var/www/shared/mysite.com` |
| WEBSCALE_SHARED_DIRS | Specifies which subdirectories are shared by `shell`, relative to the `html` subdirectory. For example: `pub/media var` |
---
# Getting Started
URL: https://docs.webscale.com/docs/getting-started/
Description: Details on getting started with Webscale


---
# Hosting V3
URL: https://docs.webscale.com/hosting-platforms/hosting-v3/
Description: Containerized application code configured in bootstrap sequences stored in
Amazon S3 buckets and launched by _invoker_, included in the [web-server and
nfs-server image families](/docs/reference/images/).



## Webscale Pro V3

### Container shell helpers

Webscale Pro V3 environments run your application in containers. To open a shell inside the application container from the NFS host, use the `shell` helper script:

```bash
shell
```

This script opens an interactive shell inside the container with the site code mounted (`/var/www/html`) and all the shared folders (`media`, `var`, etc).

---

### Deployment helper scripts

The following helper scripts are available for deployments on Webscale Pro V3 environments:

- `list-images` – lists available container images (for example tags by commit or branch).
- `tag-by-commit` – updates the deploy tag to point to an image built from a specific commit.
- `tag-by-branch` – updates the deploy tag to point to an image built from a specific branch.
- `run-deploy-and-cleanup` – runs the deployment using the current deploy tag, executes hooks, and cleans up.

These scripts are used in the [Webscale Pro V3 deployment guide](/docs/how-tos/deployment/standard/standard-deploy/) and should not be modified.

---

### Managed services

Webscale Pro V3 environments use managed services for supporting components. Typical services include:

- Database (managed relational database)
- Search (OpenSearch-compatible service)
- Cache/key-value store (Valkey-compatible cache service)
- Message queue (RabbitMQ-compatible service)
- HTTP cache (Webscale Varnish)
- HTTP relay / reverse proxy in front of the application

The exact service types and locations are defined per environment and managed by Webscale.

---

### Related how-to guides

- [Deploy a new release](/docs/how-tos/deployment/standard/standard-deploy/)
- [Magento and Shopware commands](/docs/how-tos/deployment/standard/standard-commands/)
---
# Deployments
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/deployments/
Description: Deploying code to a V4 stack



The method of deploying code depends on the stack tier used.

### Essentials

Code is deployed directly to the server in the `/shadow/www` directory.

### EKS

Code is deployed as a Helm chart through a Webscale [Kubernetes cluster](/docs/how-tos/general/kubernetes-clusters/). Each deployment installs the chart in its own namespace, verifies it, and moves traffic to it.

### All others

[CodeDirect](/docs/how-tos/codedirect/) is used to build and deploy a container
image to a cluster. Builders can be configured to deploy code automatically on
completion of a successful build, triggered externally using the
[Webscale API](https://control.webscale.com/docs/api), or launched using the
Webscale Control Panel.
---
# Overview
URL: https://docs.webscale.com/docs/overview/
Description: A brief overview of Webscale products and services


---
# Commands
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/commands/
Description: Commands for V4 hosting platforms.


---
# How-Tos
URL: https://docs.webscale.com/docs/how-tos/
Description: Guides on using the Webscale Control Panel.


---
# Protecting Your Site with a Captcha
URL: https://docs.webscale.com/docs/how-tos/web-controls/captcha-action/
Description: Configure a captcha, using a Web Control with the Challenge User action



{{% include webcontrol.md %}}

A useful action to add to a web control is the **Challenge User** action. This action will present users that match the **Condition** specified with a _Google ReCaptcha_ they must solve to prove they are not a bot. A previously validated user is not presented with a challenge. An example of when to use this type of web control is if you are seeing elevated malicious or suspicious behavior on your site, or if you have a list of IPs that you already know to be malicious.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

{{% alert color="info" title="Prerequisite" %}}
Since you’re setting a Web Control, we recommend reading [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/) before following these steps.
{{% /alert %}}

### Create the Challenge User Action

Click **+ Add action** to create an action for the new Web Control, which opens the Create Action dialog. To proceed, click **Select an Action**.

{{< figure src="/images/web_controls/create_action.png" alt="Webscale Create Action dialog in the control panel" >}}

A list of actions is now displayed. Select **Challenge User** and click the **Done** button to return to the Edit Web Control screen. Remember that you can add more than one action.

{{% alert title="Note:" %}}
When the specified **Condition** is met, the captcha will be presented to every user that meets the condition, and will continue to be presented until the user solves the captcha. The captcha action uses the hostname of the site the user is visiting, the user's IP address, and the useragent (browser, OS, device) the user is using. If a user matches the conditions of the web control, the web control sets an encrypted cookie containing this information and shows the user a captcha. When the captcha is successfully solved, it updates the cookie to state that the user passed the challenge, and the user will no longer have to solve a captcha. The action then behaves as if it were a **Continue** action, even if the user continues to match the condition of the **Web Control**.
{{% /alert %}}

When a condition is met, then all specified actions are applied to the request. You can only choose one final action. Final actions run last; the order of execution of other actions is unspecified and not necessarily in the order displayed.

## Further reading

- [Captcha pages](/docs/how-tos/advanced/microsite/#captcha-pages) in [Working with Microsites](/docs/how-tos/advanced/microsite/)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [Editing the Allowlist](/docs/how-tos/security/whitelist/)
- [Enabling Bot IP Shield](/docs/how-tos/security/bot-shield/)
---
# Configuring WMA
URL: https://docs.webscale.com/docs/how-tos/webscale-monitoring-agent/configuration/
Description: How to configure the Webscale Monitoring Agent



The Webscale Monitoring Agent (WMA) is a multipurpose program that can be
installed on a VM host to facilitate communication with Webscale. It consists of
three independent processes—metric monitoring, [log collection](
/docs/how-tos/webscale-monitoring-agent/log-collection/), and [SSH
connectivity](/docs/how-tos/webscale-monitoring-agent/ssh-connect/)
—which you can enable or disable in the configuration file.

## Configuration reference

Configure the Webscale Monitoring Agent using the file
`/etc/webscale/wma-config.json`. The Webscale control plane automatically
supplies some configuration values for VMs it creates. The file is in JSON
format with the following fields.

| Field              | Type             | Description                              | Default      | Example      |
|--------------------|------------------|------------------------------------------|--------------|--------------|
| `access_token`     | String           | Authentication token for accessing the upload endpoint.                   |              | |
| `autoupdate`       | String           | Frequency at which WMA checks for updates. A unit suffix (e.g., 's', 'm', 'h') is required. |              | `"300s"`, `"24h"` |
| `debug`            | Boolean          | Enables verbose logging for troubleshooting.        | `false`      | `true` |
| `log_config`       | Object           | Settings for managing logging streams. See table below.              |              | |
| `resource_labels`  | Array of Strings | Labels used when registering an SSH/resource host.                  |              | `["staging"]` |
| `ssh_config`       | Object           | Settings for SSH connectivity. See table below.                    |              | |

### log_config Object

| Field              | Type                | Description                               | Default      | Example      |
|--------------------|---------------------|-------------------------------------------|--------------|--------------|
| `disabled`         | Boolean             | Enables log capture when set to `false`. | `true`       | `false` |
| `log_streams`      | Array of Objects    | Array of objects, where each object defines a single logging stream. See table below.|              |   |

#### log_streams Object

| Field              | Type                | Description                              | Default      | Example      |
|--------------------|---------------------|------------------------------------------|--------------|--------------|
| `application_id`   | String              | _Required_. An application identifier to associate logs with that application.|              | `"a1yz47n4q15s"` |
| `file_patterns`    | Array of Strings    | _Required_. List of file path patterns of logs to collect. The pattern may contain wildcards (`*`) to match zero or more characters. |              | `["/home/test/custom.log"]`     |
| `name`             | String              | _Required_. A name used to identify the log stream.|              | `"my-app"` |
| `filters`          | Array of Strings    | If configured, when any of the values are found in a log line, then the log line will be captured. If not configured, then all log lines are captured, subject to `filter_regex`. | | `["CRIT"]` |
| `filter_regex`     | String              | A regular expression. When configured, any matching log lines are captured. If not configured, then all log lines are captured, subject to `filters`. | | `"CRIT\|EMERG\|ALERT"` |

### ssh_config

| Field              | Type                | Description                              | Default      | Example      |
|--------------------|---------------------|------------------------------------------|--------------|--------------|
| `address`          | String              | Used when registering an SSH host. Typically, this should not be set manually.|              | `"1.2.3.4"`|
| `via`              | String              | Used when registering an SSH host. Typically, this should not be set manually.|              | `"ssh-hosts/xyz"` |
| `disabled`         | Boolean             | Enables SSH connectivity when set to `false`.| `true`       | `false` |


Sample configuration file:
```JSON
{
  "autoupdate": "24h",
  "ssh_config": {
    "disabled": false,
  },
  "log_config": {
    "disabled": false,
    "log_streams": [
      {
        "name": "StreamName",
        "file_patterns": [
          "/home/test/custom.log"
        ],
        "application_id": "a1yz47n4q15s"
      }
    ]
  }
}
```

## Metadata configuration
WMA typically runs on servers managed by the Webscale Control Plane. For servers created in a Webscale Cluster, the metadata file (`/var/lib/webscale/metadata.json`) contains values that WMA uses unless they are overwritten by the local configuration file.
These metadata values include:
```JSON
[
	{
		"key":"WEBSCALE_API_HOST",
		"value":"api.webscale.com"
	},
	{
		"key":"WEBSCALE_ACCESS_TOKEN",
		"value":"xyz"
	},
	{
		"key":"WEBSCALE_SERVER_ID",
		"value":"abcd"
	}
]
```

{{% alert title="Note:" %}}
WMA must be restarted for configuration changes to take effect. WMA is restarted with:
```
sudo systemctl restart webscale-monitoring-agent
```

The WMA log can be viewed to verify the configuration was accepted using:
```
journalctl -u webscale-monitoring-agent
```
{{% /alert %}}
---
# Explanation
URL: https://docs.webscale.com/docs/explanation/


---
# Services
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/
Description: Services



Individual services may be controlled with `sudo systemctl _command_ _service_`.
---
# FAQ
URL: https://docs.webscale.com/docs/faq/
Description: Frequently Asked Questions



## Solutions

### Can Webscale host my application for me?
 Yes, all of Webscale’s solutions come with the ability, either by default or as an add-on option, to host your application in our cloud account. Hosting your application lets you focus on managing the functional aspects of your application, rather than managing the infrastructure. Read about our [product plans here](https://www.webscale.com/plans/).

### How do Webscale solutions differ from traditional appliances like ADC or WAF?
 Historically, ADC (Application Delivery Controller) or WAF (Web Application Firewall) functionality was available from many industry vendors as a hardware appliance. These have since evolved into software solutions that one can deploy on virtual machines. The common theme here is that they leave the management of complex infrastructure to the customer. We deliver Webscale as a pure SaaS (Software as a Service), so you do not have to worry about procuring, deploying, or maintaining the ADC or WAF. The software is cloud-hosted and managed by Webscale through its multi-tenant architecture, delivering all the functionality needed, including auto-updates, so new functionality is immediately available without any intervention on your part.

### How can Webscale protect my application from developer errors?
 It is not uncommon for developer errors to bring down applications. Webscale can automatically take scheduled (time-based or event-based) backups of the entire application and validate each backup to make sure they are usable for restoration to a fully functional application. When an application goes down due to erroneous code changes, the safest recovery option is to restore from a previously validated backup. Webscale enables the administrator to choose from a list of validated backups and restore the application successfully, preventing further downtime.

### How can Webscale protect my application against cloud outages?
 While not very common, wide-scale cloud outages may occur. Such disasters can have a significant impact on the revenue and brand reputation of the business. Webscale has disaster recovery solutions (Cloud Mirror and Cloud Rescue) that can replicate a running application in a different cloud region or an entirely different cloud provider, ensuring there is a redundant, near real-time snapshot of the application always available during a cloud outage. During the disaster, Webscale can then failover the application to the replica location and have the application running back up with its last known available state.

## Features

### What is Webscale Shield Mode?
 Often, we see applications facing DDoS (distributed denial of service) attacks from bots, slowing the application down and keeping it from responding to other valid requests or bringing it down altogether. To get ahead of this problem, the admin can enable **Webscale Shield** with a single click. Webscale Shield locks all bots out of the application instantly and validates users to only allow humans. This buys the administrators time to identify the pattern causing the attack and permanently block them before disabling the Webscale Shield.

### What is App Shield?
 The Webscale data plane includes a WAF (web application firewall) that fronts the application. Through various control mechanisms (blacklisting, Web Controls, DDoS Shield Mode, WAF rules), Webscale can block bad traffic before it gets to the application. But, if an attacker discovers the application server IP addresses, they can bypass the Webscale WAF and directly access the application servers to attack them. To solve this security problem, the Webscale **App Shield**, when enabled, only allows web requests to the application servers coming from the Webscale data plane IPs and rejects all other requests.  This ensures the only valid traffic getting through to the application comes via the Webscale data plane, and there is one place to apply all security controls to that traffic.

### What are Web Controls, and how do I use them?
 Web Controls are easy-to-use, customizable policies enforced on web requests accessing the application. They are used to control different aspects of web traffic – to tune and enhance performance, uptime, and security of the web application. The administrator can configure and enable multiple web controls and determine their execution order through the Webscale control panel.
 Some of the many use cases you can enable through web controls:

 - Block (or allow) user traffic from a particular geography.
 - Enable blue-green testing of different web application designs.
 - Enable performance optimizations based on specific request identifiers such as URLs.
 - Route application admin page requests to a separate application backend.
 - Optimize 3rd party content to speed up page load.

See the [Web Controls How-Tos](/docs/how-tos/web-controls/) for instructions on configuring Web Controls.

### What is Dynamic Site Cache?
 Web pages are increasingly personalized and dynamic, and therefore are un-cacheable since they change dynamically based on whether a user is logged in. Enabling **Dynamic Site Cache** allows caching of web pages outside the application infrastructure for users who are not logged in, from within the Webscale data plane. This significantly offloads the application to focus on checkouts and cart operations and leaves generic browsing and bot activity to be handled outside the infrastructure, leading to faster page load performance and increased cost efficiency of hosting. You can enable **Dynamic Site Cache** on a per-application basis.
 {{% alert %}}[Contact us](mailto:support@webscalenetworks.com) to learn more about how to enable **Dynamic Site Cache**.{{% /alert %}}

### What is Bot IP Shield? How do I get it?
 Webscale **Bot IP Shield** addresses the challenge of identifying known bad attackers through incoming IP addresses. **Bot IP Shield** disables, in real-time, inbound communications from IPs known to be malicious, keeping customer infrastructure secure and efficient. [Webroot’s BrightCloud® IP Reputation Service](https://www.webroot.com/us/en/business/threat-intelligence/internet/ip-reputation) powers Webscale **Bot IP Shield**. **Bot IP Shield** is available as part of [Cloud Bot Manager](https://www.webscale.com/plans/webscale-product/webscale-cloud-bot-manager/) or [Enterprise Cloud Secure](https://www.webscale.com/plans/webscale-product/webscale-enterprise-cloud-secure/).
 {{% alert %}}[Contact us](mailto:support@webscalenetworks.com) to learn more about how to enable **Bot IP Shield** in your account.{{% /alert %}}

### What is Cloud Bot Manager? How is it offered?
 **Cloud Bot Manager** is Webscale’s comprehensive multi-cloud bot management solution that combats the rapidly growing threat of malicious bots while improving performance and delivering higher RoI. It includes:
 - Instant Attack Detection
 - Real-Time Bot Mitigation
 - Bot IP Directory
 - Real-Time Monitoring, Reporting and Management
 - Intelligent Caching
 **Cloud Bot Manager** can be enabled with just DNS changes to protect any application on any hosted environment. It is also available as part of [Enterprise Cloud Secure](https://www.webscale.com/plans/webscale-product/webscale-enterprise-cloud-secure/), Webscale’s enterprise security suite. Learn more on [Webscale **Cloud Bot Manager**](https://www.webscale.com/plans/webscale-product/webscale-cloud-bot-manager/).

## Pricing

### What is the pricing model for Webscale solutions?
  Webscale plans are priced like any SaaS, with monthly recurring fees and sometimes, a one-time setup fee. The plan that you choose depends on various factors relating to your needs. The need for Webscale hosting, the number of web applications that need to be managed by Webscale, the average number of visitors to each web application, and other considerations are all factors to consider.
  {{% alert %}}[Contact us](mailto:support@webscalenetworks.com) to discuss your options.{{% /alert %}}
---
# Stacks
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/
Description: Stacks available in the V4 hosting platform.


---
# How to Customize Webscale's Autoscaling
URL: https://docs.webscale.com/docs/how-tos/advanced/customize-auto-scaling/
Description: How to customize the autoscaling environment in the Webscale Control Panel



Webscale autoscaling has a diversity of rulesets used to scale dynamically. Webscale monitors the following metrics on each of the application servers and then uses the returned value in combination with a manually defined value over time to decide if and when to scale the cluster in/out:

 - CPU % Utilization
 - I/O Wait %
 - Kilobytes/second
 - Load Average
 - Memory Usage %
 - Requests/Second

Some examples of autoscaling triggers are "Scale out when Load Average of the system has been greater than 1.25 for 1 minute", or conversely, "Scale in when Load Average of the system has been less than 0.50 for 1 minute".

The conditions you can utilize are:
 - has been less than
 - has been greater than
 - will be less than
 - will be greater than

Once one of these conditions is met, Webscale triggers the scale in/out. Define a minimum and maximum desired cluster size that limits these conditions. Set the minimum to what your contract defines for you, for example, `1`. The max setting to use is one that is suitable to handle any surges of legitimate traffic while still within your cloud account quota limit. Set it to a reasonable max (for example, `10`) to ensure buffer room for any traffic surges but also to keep it low enough so account expenses remain minimal in the case of, for example, unprecedented bot traffic hitting the site.

Find the cluster settings in the **Account Settings** section of the Webscale control panel.

## Customize Autoscaling
|   |   |
|---|---|
|{{< figure src="/images/account-settings.jpg" width="75%" alt="Account Settings" >}}| 1. Log in to the [Webscale control panel](https://control.webscale.com) and click the gear <i class="fa fa-cog" aria-hidden="true"></i> on the upper right, then select **Account Settings** from the menu.|
|{{< figure src="/images/view-clusters.jpg" width="75%" alt="Clusters List" >}}| 2. Click **Clusters** from the top menu bar to view the cluster information. Click the **Edit** button to view the details for that cluster.|
|{{< figure src="/images/cluster-settings.jpg" width="75%" alt="Autoscaling Configuration" >}}| 3. Make your changes to the min and max server counts for the cluster and other details, including when the cluster scales out or in. Click the **Save** button at the bottom of the screen to confirm any changes made to the cluster settings.|

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# How-Tos
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/how-tos/
Description: Guides for the V4 hosting platform.


---
# Reference
URL: https://docs.webscale.com/docs/reference/
Description: Reference docs for Webscale


---
# API Reference
URL: https://docs.webscale.com/docs/api/
Description: API Reference docs for Webscale


Placeholder. This is diverted in production by the Webscale Control service.
---
# Configuration
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/stacks/configuration/
Description: Principles of stack configuration



## Connecting to an existing stack
When deploying multiple stacks within the same environment, the Webscale Control Plane acts as a central dependency resolver.
Instead of referencing cloud-provider resources directly, a stack may reference outputs from another stack

For example, you may wish to deploy an add-on stack into an existing network or require the database endpoint of an RDS database. To refer to these values, you can provide references to the outputs from a different stack.

### Examples
```
  "data_subnets": "/v2/stacks/{stack-id}/outputs/data_subnets"
  "public_subnets": "/v2/stacks/<{stack-id}/outputs/public_subnets"
  "db_endpoint": "/v2/stacks/<{stack-id}/outputs/db_endpoint"
  "db_password_secret_name": "/v2/stacks/<{stack-id}/outputs/db_password_secret_name"
```

*Note: A stack that is referenced by another stack cannot be deleted until the dependency is removed.*
---
# Latest Updates
URL: https://docs.webscale.com/docs/latest-updates/
Description: Thirty most recent updates


{{< recently-updated >}}
---
# AWS Setup
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/aws-setup/
Description: Setup tasks for customer-owned AWS accounts



In the scope of an enterprise-level plan, the Webscale Control Plane can provision and manage resources in a customer-provided AWS account. This page describes setup necessary to allow the Control Plane to access an account. It is not necessary when using a plan that includes Webscale-provided AWS accounts.

### How It Works
1. **Setup the IAM Permissions Boundary:** A customer-managed IAM policy defines the maximum permissions any role created by Webscale can possess. It explicitly denies actions that allow privilege escalation (e.g., creating IAM users, modifying policies without oversight, or creating access keys).

2. **Setup the IAM Role:** This is the cross-account role assumed by Webscale. Its policy contains an iam:PermissionsBoundary condition that permits role creation and policy attachment only if the target role has the boundary attached. The role must belong to the same AWS account that the Stack will be provisioned with.

3. **Stacks:** Provide the `permissions_boundary_arn` and the `provisioner_role_name` as variables when creating a Stack. Stack definitions attach the customer's boundary ARN to all child IAM roles. Any attempts to assume a role in the customer account without the boundary ARN reference will fail.

### CloudFormation Template

The following template is a guideline for creating the IAM Permissions Boundary and IAM Role described in steps 1 and 2 above.

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: "Provisions the Webscale cross-account role and strictly enforces a permissions boundary on all infrastructure deployed by Webscale."

Resources:
  # -------------------------------------------------------------------
  # The Permissions Boundary
  # -------------------------------------------------------------------
  CustomerProvisioningBoundary:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: WebscaleProvisioningBoundary
      Description: "Maximum allowed permissions for roles provisioned by the Webscale control plane."
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Sid: AllowAppAndInfrastructureServices
            Effect: Allow
            Action:
              - ec2:*
              - eks:*
              - ecr:*
              - elasticloadbalancing:*
              - autoscaling:*
              - logs:*
              - cloudwatch:*
              - secretsmanager:GetSecretValue
              - secretsmanager:DescribeSecret
              - secretsmanager:ListSecretVersionIds
              - secretsmanager:BatchGetSecretValue
              - kms:Decrypt
              - kms:GenerateDataKey*
              - kms:DescribeKey
              - ssm:GetParameter
              - pricing:GetProducts
            Resource: "*"
          - Sid: AllowKarpenterIAMReadsAndPassRole
            Effect: Allow
            Action:
              - iam:ListInstanceProfiles
              - iam:GetInstanceProfile
              - iam:PassRole
              - iam:CreateServiceLinkedRole
            Resource: "*"
          - Sid: ExplicitDenyPrivilegeEscalation
            Effect: Deny
            Action:
              - iam:CreateUser
              - iam:CreateRole
              - iam:CreatePolicy
              - iam:CreateAccessKey
              - iam:CreateLoginProfile
              - iam:PutRolePolicy
              - iam:PutUserPolicy
              - iam:AttachRolePolicy
              - iam:AttachUserPolicy
              - iam:DetachRolePolicy
              - iam:DeleteRolePolicy
              - iam:UpdateAssumeRolePolicy
              - iam:AddUserToGroup
            Resource: "*"

  # -------------------------------------------------------------------
  # The Provisioner Role
  # -------------------------------------------------------------------
  WebscaleCrossAccountRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AccountProvisioner
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS: "arn:aws:iam::725084300153:root"
            Action: sts:AssumeRole
      Policies:
        - PolicyName: EnforcePermissionsBoundary
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Sid: ReadOnlyActions
                Effect: Allow
                Action:
                  - ec2:Describe*
                  - iam:List*
                  - iam:Get*
                  - eks:Describe*
                  - eks:List*
                  - rds:Describe*
                  - rds:List*
                  - elasticache:Describe*
                  - elasticache:List*
                  - es:Describe*
                  - es:List*
                  - mq:Describe*
                  - mq:List*
                  - secretsmanager:Describe*
                  - secretsmanager:Get*
                  - secretsmanager:List*
                  - route53:Get*
                  - route53:List*
                  - dlm:Get*
                  - ecr:Describe*
                  - ecr:Get*
                  - ecr:List*
                  - kms:DescribeKey
                  - kms:ListGrants
                Resource: "*"

              - Sid: ManageInfrastructure
                Effect: Allow
                Action:
                  - ec2:*
                  - eks:*
                  - rds:*
                  - elasticache:*
                  - es:*
                  - mq:*
                  - secretsmanager:*
                  - route53:*
                  - dlm:*
                  - ecr:*
                  - kms:CreateGrant
                  - kms:RevokeGrant
                  - kms:Decrypt
                  - kms:GenerateDataKey
                  - kms:GenerateDataKeyWithoutPlaintext
                Resource: "*"

              - Sid: IAMRoleCreationWithBoundary
                Effect: Allow
                Action:
                  - iam:CreateRole
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:role/webscale-*"
                Condition:
                  StringEquals:
                    iam:PermissionsBoundary: !Ref CustomerProvisioningBoundary

              - Sid: IAMRolePolicyModificationsWithBoundary
                Effect: Allow
                Action:
                  - iam:PutRolePolicy
                  - iam:AttachRolePolicy
                  - iam:DetachRolePolicy
                  - iam:DeleteRolePolicy
                  - iam:PutRolePermissionsBoundary
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:role/webscale-*"
                Condition:
                  StringEquals:
                    iam:PermissionsBoundary: !Ref CustomerProvisioningBoundary

              - Sid: IAMRoleLifecycle
                Effect: Allow
                Action:
                  - iam:DeleteRole
                  - iam:UpdateAssumeRolePolicy
                  - iam:TagRole
                  - iam:UntagRole
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:role/webscale-*"

              - Sid: IAMInstanceProfileManagement
                Effect: Allow
                Action:
                  - iam:CreateInstanceProfile
                  - iam:DeleteInstanceProfile
                  - iam:AddRoleToInstanceProfile
                  - iam:RemoveRoleFromInstanceProfile
                  - iam:TagInstanceProfile
                  - iam:UntagInstanceProfile
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:instance-profile/webscale-*"

              - Sid: IAMOIDCProviderManagement
                Effect: Allow
                Action:
                  - iam:CreateOpenIDConnectProvider
                  - iam:DeleteOpenIDConnectProvider
                  - iam:TagOpenIDConnectProvider
                  - iam:UntagOpenIDConnectProvider
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:oidc-provider/*"

              - Sid: IAMPassRoleRestricted
                Effect: Allow
                Action: iam:PassRole
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:role/webscale-*"

              - Sid: AllowServiceLinkedRoleCreation
                Effect: Allow
                Action:
                  - iam:CreateServiceLinkedRole
                Resource: !Sub "arn:aws:iam::${AWS::AccountId}:role/aws-service-role/*"
                Condition:
                  StringEquals:
                    iam:AWSServiceName:
                      - "eks.amazonaws.com"
                      - "eks-nodegroup.amazonaws.com"
                      - "elasticloadbalancing.amazonaws.com"

Outputs:
  CrossAccountRoleName:
    Description: "Provide this role name when creating Stacks so the provisioner can assume the role."
    Value: !Ref WebscaleCrossAccountRole

  PermissionsBoundaryArn:
    Description: "Provide this ARN when creating Stacks to include the boundary."
    Value: !Ref CustomerProvisioningBoundary
```

---
---
# Setup
URL: https://docs.webscale.com/docs/how-tos/ssh-gateway/setup/
Description: How to set up your user account to use SSH Gateway


Once you have set up your user account as described below, you will be
able to access any host that is [registered with SSH
Connect](/docs/how-tos/ssh-connect/register-hosts/).

To set up your user account for SSH Gateway, two pieces of information are
needed:

* _An SSH username._ This name will identify you to Webscale, and must be
  globally unique among Webscale users.
* One or more _SSH public keys_. These keys are used to verify your identity.

## Username

You already have an SSH username that is automatically assigned. You can
see it on [your profile page](https://control.webscale.com/profile)&nbsp;<i
class="fas fa-external-link-alt" aria-hidden="true"></i>.

{{< figure src="/images/ssh-gateway/ssh-username.png" alt="Settings panel showing SSH username" >}}

You can change your SSH username on the profile page. Be aware that past
usernames cannot be reused in the future, even by the same user.

## Public Keys

SSH keypairs are the preferred system of securing access to servers without
using account passwords. An SSH keypair consists of a public key and a private
key that are generated together.

The private key is never uploaded into Webscale systems, and remains with the
user. The public key can be shared freely, and this is what is shared with
Webscale.

To generate a keypair on Mac or Linux, or anywhere the `ssh` command line tool
is installed (e.g., [WSL2](https://learn.microsoft.com/en-us/windows/wsl/about)&nbsp;<i
class="fas fa-external-link-alt" aria-hidden="true"></i>
for Windows), you can use the `ssh-keygen` tool:

```
ssh-keygen -f ~/.ssh/webscale
```

This will generate a keypair and store it in two files, `webscale` (private
key) and `webscale.pub` (public key), in the `.ssh` directory of your home
folder.

You should now configure SSH to use this keypair when accessing SSH Gateway.
Run the following command in a terminal to add the necessary config:

```
echo "Host ssh.webscale.com\n\tIdentityFile ~/.ssh/webscale" >> ~/.ssh/config
```

Next, copy the contents of `webscale.pub`. You can show it on the command line
with the command:

```
cat ~/.ssh/webscale.pub
```

Now, navigate to [your profile page](https://control.webscale.com/profile)&nbsp;<i
class="fas fa-external-link-alt" aria-hidden="true"></i>,
scroll to the _SSH public keys_ section, and click the button labeled
_Add SSH public key_. Paste the contents of `webscale.pub` into the field
labeled _Public key_, and click _Save_.

{{< figure src="/images/ssh-gateway/ssh-public-keys.png" alt="SSH public keys form" >}}

You should see the key appear above the _Add SSH public key_ button. You can
upload up to three SSH public keys.

## Ready

Once you know your SSH username and have uploaded a public key, you are ready
to connect to any host that is accessible from SSH Connect. See [Connecting to
Hosts](/docs/how-tos/ssh-gateway/connecting-to-hosts/) for
instructions on using SSH, SCP, SFTP, and port forwarding.
---
# Connecting to Hosts
URL: https://docs.webscale.com/docs/how-tos/ssh-connect/connecting-to-hosts/
Description: How to connect to registered SSH hosts



Once a host is registered with Webscale, it will be accessible to access over SSH using the Webscale Control Plane as long as the following requirements are met:

- Webscale Monitoring Agent (WMA) is running on the host with SSH enabled.
- The host's network allows connections over port 22 from the SSH Connect middleware

On the SSH Connect page, a drawer will list the hosts that have been registered and approved. Clicking a host will initiate a connection with that host and launch a terminal window.

{{< figure src="/images/ssh-connect/ssh-connect-drawer.png" width="40%" alt="SSH Connect drawer" >}}

Click the Edit icon to manage registered hosts.

### Accessing a host via a bastion

If the host is not publicly accessible, the bastion used to access the host must be a registered SSH host as well. Users can associate SSH hosts with their corresponding bastion by selecting the registered bastion in the "Via" dropdown in the SSH host management editor. The "Via" reference allows the SSH Connect facility to connect to a host by way of a different host.

{{< figure src="/images/ssh-connect/edit-via-host.png" width="85%" alt="Edit via host field" >}}
---
# Log Collection
URL: https://docs.webscale.com/docs/how-tos/webscale-monitoring-agent/log-collection/
Description: How to use WMA log collection



The Webscale Monitoring Agent can be configured to aggregate logs in the Webscale Control Panel for easy filtering, searching, and viewing. This is done by enabling log collection in the WMA configuration file.

Logs are aggregated as "Custom Logs" and can be viewed in the Webscale Control Panel. For more information, see [Configuring and Viewing Custom Logs](/docs/how-tos/advanced/custom-logs/).

## Log streams
A log stream is simply a collection of logs, aggregated for easy filtering and searching

### Name
A descriptive stream name will help users more easily filter and locate desired logs.

### File patterns
The log stream should specify one ore more files to watch for new logs to be written to. Any file(s) that match the file pattern(s) specified will be aggregated. A wildcard (*) can be used to match multiple logs in a directory.

### Application ID
Logs aggregated by WMA must be associated with a Webscale Application. To find this ID, send a GET to /v2/applications and use the 12 character alphanumeric ID in the application href for the desired application.

## Sample log config
```JSON
...
"log_config": {
    "disabled": false, # When true log collection will be disabled.
    "log_streams": [
      {
        "name": "stream_name", # A name for stream.
        "file_patterns": [
          "/home/test/custom.log", # A specific file to capture logs from
          "/etc/nginx/*.log", # Will capture all files in /etc/nginx that end with '.log'
        ],
        "application_id": "wxyz1234abcd" # Application id to post logs.
      }
    ]
  }
...
```
---
# Connecting to Hosts
URL: https://docs.webscale.com/docs/how-tos/ssh-gateway/connecting-to-hosts/
Description: How to connect to registered SSH hosts with SSH Gateway


Once you have [set up an SSH username and public
key](/docs/how-tos/ssh-gateway/setup/) and you have
[registered hosts in SSH
Connect](/docs/how-tos/ssh-connect/register-hosts/),
you are ready to connect using SSH Gateway.

Examples below are written for the [OpenSSH](https://en.wikipedia.org/wiki/OpenSSH)&nbsp;<i
class="fas fa-external-link-alt" aria-hidden="true"></i>
suite of command-line tools (`ssh`, `scp`, and `sftp`). These tools are
installed by default on Mac, Linux, and Windows
[WSL2](https://learn.microsoft.com/en-us/windows/wsl/about)&nbsp;<i
class="fas fa-external-link-alt" aria-hidden="true"></i>.

## Connection basics

When connecting to SSH Gateway, you will use a _connection string_ that
incorporates your SSH username, the name of the SSH connect host you are
trying to connect to, and `ssh.webscale.com`, joined together with `@`
symbols.

Use the hostname shown on the SSH Connect drawer, not the DNS hostname for the
server.

{{< figure src="/images/ssh-gateway/ssh-connect-drawer.png" alt="SSH Connect Drawer" >}}

For instance, for a user with the SSH username `joesample`, who is trying to
connect to a host that is named `sampleco-cp1`, the connection string would look
like:

```
joesample@sampleco-cp1@ssh.webscale.com
```

## SSH for login and remote exec

You can open a login shell to a host using SSH Gateway and the `ssh` command:

```
ssh joesample@sampleco-cp1@ssh.webscale.com
```

If you would like to execute a command on the remote server, you can append it
to the `ssh` command as usual. For instance, to run `ps -aux` on the server
and see its output locally, run:

```
ssh joesample@sampleco-cp1@ssh.webscale.com ps -aux
```

## Transferring files with SCP

You can transfer files to and from your local computer using the `scp` command.
To copy a file called `data.json` from the server to your local machine, run:

```
scp joesample@sampleco-cp1@ssh.webscale.com:data.json .
```

To copy the file from your local directory to the remote server, run:

```
scp data.json joesample@sampleco-cp1@ssh.webscale.com:
```

## Transferring files with SFTP

The `sftp` command can be used to interactively transfer files to and from
the server, using subcommands similar to the historical `ftp` program.

The exact usage of `sftp` is out of scope for this document, but you can connect
to a host using:

```
sftp joesample@sampleco-cp1@ssh.webscale.com
```

## SSH for local port forwarding

The `ssh` command can securely forward traffic from a local network port to a
port on a remote server. This allows, for instance, connecting to a remote
database using local tools.

For example, a user with MySQL DB running on port 3306 on a remote server
could make that traffic available on port 5000 of his local computer like this:

```
ssh -N -L 5000:localhost:3306 joesample@sampleco-cp1@ssh.webscale.com
```

And then connect to it locally, for example using the `mysql` command line tool:

```
mysql -h 127.0.0.1 -P 5000 -u <username> -p
```

## Conclusion

SSH Gateway gives access to remote hosts using the industry standard SSH
protocol. It does not require the use of a browser like SSH Connect does, and
unlocks features like file transfers, port forwarding, and remote command
execution. Use it for convenient access to your servers and data inside the
Webscale cloud.
---
# Connecting with FileZilla
URL: https://docs.webscale.com/docs/how-tos/ssh-gateway/connecting-with-filezilla/
Description: How to connect FileZilla to Webscale servers via SSH Gateway


<!-- Paste markdown body below this line -->
This guide shows you how to configure FileZilla to access your application files through the Webscale SSH Gateway.

### **Prerequisites**

* An [SSH Key pair](https://docs.webscale.com/how-tos/ssh-gateway/setup/) added to your Webscale user profile.
* The [**SSH Gateway** hostname](https://docs.webscale.com/how-tos/ssh-gateway/connecting-to-hosts/) \- `ssh.webscale.com`.
* Your **Application HOSTNAME** (e.g., `myapp-staging`).

### **Step 1: Configure General Connection Settings**

1. Open FileZilla and navigate to **File \> Site Manager**.
2. Click **New Site** and name it (e.g., "Webscale SSH Gateway").
3. Set **Protocol** to `SFTP - SSH File Transfer Protocol`.
4. Set **Host** to your assigned gateway address (e.g., `ssh.webscale.com`).
5. Set **Logon Type** to `Key file`.

### **Step 2: Set the User String and Key**

In the **User** field, you must use the specific gateway format: `<your_username>@<application-hostname>`

**Example:** `jdoe@myapp-staging-nfs`

Finally, browse to and select your **Private Key file**.

### **Step 3: Connect**

Click **Connect**. If prompted about an unknown host key, verify the fingerprint and click **OK**. You should now see your remote directory tree.

{{< figure src="/images/ssh-gateway/connect.png" alt="FileZilla Site Manager connection settings" >}}

Here is an example of what you should see:

{{< figure src="/images/ssh-gateway/result.png" alt="FileZilla connected to remote directory" >}}
---
# Registering Hosts
URL: https://docs.webscale.com/docs/how-tos/ssh-connect/register-hosts/
Description: How to register hosts



In order to access a host through SSH Connect, the host must first be registered with Webscale in the appropriate account. This is a two step process (registration followed by approval).

## Registering SSH hosts

The first of these steps can be done either through the API directly or via the Webscale Monitoring Agent (WMA) running on the host with SSH enabled.
{{% alert title="Note:" %}}
To allow SSH access through private networks the IP of the SSH Connector middleware is `3.217.2.82`
{{% /alert %}}

### Webscale Monitoring Agent Registration
When SSH is enabled on WMA, the agent will reach out directly to Webscale's API with the relevant information needed to register including name (hostname), address, and host keys.  Associating the server with a via host (bastion) must be done through the Control Plane unless the via host reference is also provided in the WMA configuration.

### Registration of static servers as hosts

To register a static server as an SSH host (a non-cluster server), install the Webscale Monitoring Agent on the server and configure it according to the following steps:

Create a Service User: First, create a service user through the Webscale API for your account. This service user will be responsible for registering the host with Webscale, and logging SSH activity.
{{% alert title="Note:" %}}
Please refer to the [Service User Configuration Guide](/docs/how-tos/general/service-users/) for detailed instructions on creating a service user.
{{% /alert %}}

Grant Permissions: Ensure that the service user is granted root-level "Cluster Service User" permissions.

Configure the WMA: When the service user is created, an access key will be provided.

Take the service user's access key and configure it in the Webscale Monitoring Agent (WMA) by setting it as the `access_token` property in the WMA configuration file (/etc/webscale/wma-config.json).

Add an enabled `ssh_config` to the same file.

{{% alert title="Note:" %}}
Please refer to the [WMA Configuration Guide](/docs/how-tos/webscale-monitoring-agent/configuration/) for detailed instructions on supplying this configuration.
{{% /alert %}}

Automatic Registration: After completing these steps, the WMA will register the static server host with Webscale. The host will be available for SSH access once approved.

### Registering through the API
If registering through the API, please reference the appropriate documentation [here](https://control.webscale.com/docs/api).

| Field            | Description              |
| ---------------- | ------------------------ |
| Name*            | This is what the host will be referred to in the Control Panel. This can be changed later. WMA registration will automatically default to the hostname. |
| Address*         | The address used to access the host. If this is a private address, you will want to include via (below). |
| Host Keys        | The host keys of the host. WMA registration will fetch these automatically. |
| Via              | The registered host that serves as a jump through to access a privately accessible host. |

{{% alert title="Note:" %}}
When registering a host with a Via bastion, ensure you use the correct address for the host. If the host is in a private subnet, use its private address, which should be accessible from the bastion.
{{% /alert %}}

## Approving SSH hosts

Registering the host will make it available for approval in the SSH connect management table. A user with authority to
PATCH /v2/ssh-hosts
(included in Editor role) should then confirm the address and name of the host and click approve to make the host accessible through SSH Connect.

{{< figure src="/images/ssh-connect/approve-host.png" width="75%" alt="Approve host dialogue" >}}

Hosts registered by the Webscale Monitoring Agent on Webscale managed cluster servers will be automatically approved.

Registered, but unapproved hosts **will not** appear in the SSH connect drawer.
---
# SSH Connect
URL: https://docs.webscale.com/docs/how-tos/webscale-monitoring-agent/ssh-connect/
Description: How to use enable SSH Connect through WMA



The Webscale Monitoring Agent can be used to facilitate easy SSH access to authorized users directly via the Webscale Control Plane. Enabling SSH Connect within WMA will register the host with the Webscale Control Plane and allow the WMA to manage Webscale users on the host.

# Registration
In order to connect to a host via SSH Connect, that host must be registered with Webscale. ([See SSH Connect documentation for more details on registration](/docs/how-tos/ssh-connect/register-hosts/).) When WMA is started with ssh enabled, the WMA will attempt to register the host automatically. Upon successful registration, it will then subscribe to Webscale's Pub/Sub API to receive any user updates for the host. This allows users to be created and removed on the host as needed by the SSH Connect facility. (See [Connecting to Hosts](/docs/how-tos/ssh-connect/connecting-to-hosts/)

# User management
Users created by the SSH Connect facility will be created with a name that corresponds to their Webscale registered email followed by an underscore '_' and their Webscale API ID. All session activity over SSH Connect is recorded and session logs can be accessed through the Webscale Control Plane. If a user's access is revoked, the WMA will remove that user from the registered host.
---
# Building images
URL: https://docs.webscale.com/docs/how-tos/codedirect/build-image/
Description: How to build a container image from a source repository using CodeDirect



This guide shows you how to build a container image from source code stored in a repository using **Webscale CodeDirect**. The resulting image will be pushed to your configured image registry. You will also learn how to manually trigger a build and view its logs.

---

## Prerequisites

Before you begin, ensure you have:

- A source repository that contains a **Dockerfile**

- An image registry configured under **Providers**

{{% alert title="Note:" %}}
Follow the steps below to configure an AWS ECR registry:
 - Go to the **Providers** tab
 - Edit an AWS provider
 - Enable **Use for ECR**
 - Provide the registry endpoint
 - Specify a repository
{{% /alert %}}

---

## 1. Create a new Builder

1. Go to: [control.webscale.com/builders](https://control.webscale.com/builders)


2. Click the **blue plus (+)** button to create a new Builder.

You will see configuration sections for:

- Build context
- Image destination
- Build configuration
- Build triggers

We will focus on the required fields in this guide.

---

## 2. Configure the build context

1. Expand the **Build context** panel and click **Connect a repository** or select an already connected repository.
2. Follow the prompts to authorize a connection to your repository.
3. After completing the connection, return to the Builder and select your repository from the dropdown.

---

## 3. Specify the image destination

1. Expand the **Image destination** panel and choose your configured **Image registry**.
2. Select the **Image repository** where the built image will be pushed.

---

## 4. Set the build configuration

1. Expand the **Build configuration** panel and provide the **relative path** to the Dockerfile in your source repository.

---

## 5. Optionally specify build triggers

If you would like a build to be triggered whenever code is pushed to the repository, select "Build on commit" and specify which branches you would like to trigger a build.

Otherwise, leave this section blank.

---

## 6. Save the Builder

Click **Submit** to save the Builder.

You now have a Builder capable of producing container images.

---

## 7. Manually trigger a build

1. In the Builders list, locate your newly created Builder.
2. Click the **play** (▶) button next to it.
3. Leave the source reference at **HEAD** and click **Submit**.

This action creates a new build task.

---

## 8. Monitor the build progress

1. Watch for the **spinning arrows** icon in the top-right corner of the Control Panel. This indicates that a task is running.
2. Click the icon, then click **Zoom** to view the build logs.

Look for key log entries such as:

- “Cloning git repository…” — confirms the source repo is being pulled.
- “Checking out specific commit: <SHA>” — shows which commit was used.
- “Pushing image to …” — indicates the registry, repository, and tag for the final image(s).

✅ indicates the build was successful.
❌ indicates the build failed.

---

## Result

You have successfully:

- Created a CodeDirect Builder
- Connected it to a source repository
- Configured your output image registry
- Triggered a manual build
- Viewed the build logs
---
# Files and template substitution
URL: https://docs.webscale.com/docs/how-tos/codedirect/files-in-build-context/
Description: How to include files and use template substitution in the container build context



This guide will show you how to provide files to your CodeDirect container build context. These files may include secret references to secrets securely stored with Webscale and substituted at build time.

## Prerequisites

Before you begin, ensure you have:
  - A builder created and saved
  - The file you want included in your build context uploaded to [**Webscale Files**](https://docs.webscale.com/how-tos/general/files/)

---
## Add file to build context
1. Click the **Edit** icon for the Builder you would like to modify.
2. Expand the Build context panel and select the **File** archive and **Path** for the specific file you would like to include in the build context.
3. Enter a relative **mount path**. This is where the file will be mounted in the container. This must not start with a `/`.
4. If the file is a template file and you would like the value template references to be substituted at build time, check the **Template substitution** box.

## How to use template substitution
If there are secure values that are not safe to store in the Webscale File directly, but need to be injected into the build context, you can utilize value templates in your file and specify that template substitution should occur during the build. This allows you to securely inject secrets into your build context.

A value template can be specified using the syntax: `$()`. Inside the parens, include the relevant function call. For example, to inject a secret your file might look like this:
```
{
  "db": {
    "username": "admin",
    "password": "$(secret("secrets/efgh1234abcd"))"
  }
}
```

Where `secrets/efgh1234abcd` is a reference to a secret stored with Webscale. When the build context is prepared, the contents of that secret will replace the template reference, leaving the file as follows:

```
{
  "db": {
    "username": "admin",
    "password": "mysecurepassword"
  }
}
```

### Uploading secrets to Webscale

1. To upload a secret to your Webscale account, send a POST request with a valid authorization token to `/v2/secrets`. Refer to the "Create a secret" API documentation [here](https://control.webscale.com/docs/api).
2. Record the secret href that is returned from the API. This reference is what should be used in the template file, as shown in the above example (`secrets/efgh1234abcd`).

### How to use JSON secrets
Secrets may be of type "application/json" in which case, the secret reference in your template file can include the relevant key path to a specific part of your secret content.

For example:

```
POST /v2/secrets

{
  "mime_type": "application/json",
   "content": {
      "db": {
        "username": "admin",
        "password": "mysecurepassword"
      }
    }
}
```
The username and password in this secret could be referenced in your template file as follows:
```
{
  "db": {
    "username": "$(secret("secrets/efgh1234abcd", "db.username"))",
    "password": "$(secret("secrets/efgh1234abcd", "db.password"))"
  }
}
```
Note that the JSON key is a dot separated optional second argument provided to the secrets expression. If the second argument is omitted, the entire secrets content will be injected.
---
# Builders
URL: https://docs.webscale.com/docs/how-tos/codedirect/builders/
Description: A reference for creating and managing CodeDirect Builders



This document describes the configuration attributes available for CodeDirect Builders. A Builder is responsible for performing builds based on the configuration provided. It defines the source context, build resources, build triggers, and target destination for building and storing a container image.

## Build context
These settings define the source materials and file inputs used during the build process.

#### Source repository
The source repository that contains the Dockerfile from which the image will be built.

#### Files
A list of specific files to include in the build context. Use this to include required configuration files or assets that exist outside of the source repository but are needed in the build context at build time. [Template substitution](/docs/how-tos/codedirect/files-in-build-context/) can be used to inject secrets into these included files.

### Environment variables
Key/value pairs that are included in the build context. Value templates can be used within the environment variable value to inject values using the syntax below. Keys cannot contain value templates.

To indicate a value template, use the syntax: `$()`. Inside the parens, include the relevant function call. For example:
```
$(secret("secrets/efgh1234abcd"))
```

Where `secrets/efgh1234abcd` is a reference to a secret stored with Webscale. When the build context is prepared, the contents of that secret will replace the template reference.

---

## Image destination
These settings determine where the final container image will be stored after a successful build.

#### Image registry
The image registry where the image will be pushed. This service must be pre-configured in your Providers settings before it can be selected here.

#### Image repository
The specific repository name within the selected registry where the image will be stored.

#### Image tags
A list of custom tags to apply to the image. You can define static tags (e.g., `production`) or use dynamic variables to automatically include build metadata.

To use a variable, wrap the variable name in `$()`:

* **`$(BRANCH)`**: The name of the git branch (e.g., `main`).
    * *Usage:* `branch-$(BRANCH)`
* **`$(COMMIT)`**: The specific git commit short sha.
    * *Usage:* `build-$(COMMIT)`
* **`$(DATE)`**: The date the build occurred. This variable optionally accepts a Ruby `strftime` format string inside parentheses.
    * *Usage:* `$(DATE(%Y%m%d))` resolves to `20250115`
    * *Usage:* `v1.$(DATE(%m-%d))` resolves to `v1.01-15`

#### Include commit tags?
* **Enabled:** Tags associated with the Git commit will be included as tags when pushed to the target repository.
* **Disabled:** Tags associated with the Git commit will be ignored.

---

## Build configuration
These settings control the technical execution of the build and the resources allocated to it.

#### Dockerfile path
The path to the Dockerfile within your source repository (relative to the root). This file contains the instructions used to create the image.

#### Platform
The target architecture for the image.
* **linux/amd64:** Standard Intel/AMD 64-bit architecture.
* **linux/arm64:** ARM-based 64-bit architecture.

#### CPU
The amount of CPU computing power allocated to the build runner. 1000 millicores equals 1 full CPU core.

#### Memory
The amount of RAM allocated to the build runner, measured in Mebibytes (MiB).

---

## Build triggers
These settings define the automation rules for when a build should start.

#### Included branches
A list of branches that will trigger this builder. You can use wildcards (`*`) to match multiple branches (e.g., `feature/*` matches all feature branches). If no included branches are specified, all branches are included.

#### Excluded branches
A list of branches to ignore, even if they match the **Included branches** list. This is useful for preventing builds on specific maintenance or test branches.

#### Build on commit
* **Enabled:** A build starts automatically whenever code is pushed to a matching branch.
* **Disabled:** Builds must be started manually.

---

## Deployment
These settings concern additional actions that will be taken upon successful completion of a build.

### Target clusters
To integrate your container images directly into your deployment pipeline, add one or more managed clusters to this field. When the builder successfully completes a build, these target clusters will be updated with the new container image and a new deployment using that image will be created.
---
# Deploy egress proxy
URL: https://docs.webscale.com/docs/how-tos/egress-proxy/deploy/
Description: This guide outlines the steps to deploy an egress proxy.



## Prerequisites
Before you begin, ensure that the environment that you want to use an egress proxy in has an NFS server, and you have access to ssh to it.

## 1. Check the version of the NFS server
From the command line on the NFS server, run the following cat command to check the version. If the `/etc/webscale/image` file is not exist, the NFS is running an older version.

```bash
$ cat /etc/webscale/image
nfs-server-2026.6
```
If the version of the NFS server is less than 2026.6, open a support ticket to have the NFS server upgraded.

## 2. Create an origin certificate
Go to the application menu for any application in the hosted the environment and choose "Origin certificate". Enter all hostnames for the sites that will be proxied. Download the key and the certificate.

{{< figure src="/images/egress-proxy/origin_certificate.png" width="12%" alt="Origin certificate" >}}

## 3. Upload certificates to NFS server
Using your preferred editor on the NFS server, copy the content of the downloaded certificate to the file `/etc/egress-proxy/origin.crt`. Put the key in `/etc/egress-proxy/origin.key`.

## 4. Start egress proxy service
Use the following command to enable and start the egress proxy service. It will automatically start on subsequent reboots.

```bash
sudo systemctl enable --now egress-proxy.service
```

## 5. Monitor and verify logs
To confirm the proxy is working or to troubleshoot connection issues, monitor the egress proxy log file.
Use tail to watch requests as they arrive at the proxy:

```bash
tail -f /var/log/egress-proxy.log
```
---
# Configure web servers
URL: https://docs.webscale.com/docs/how-tos/egress-proxy/configure/
Description: Follow these steps to configure a web server to route its outbound traffic through the egress proxy.



## Prerequisites
Before you begin, ensure you have setup an NFS server with egress-proxy.

## 1. Configure web server cluster
Configure metadata that tells the system where the proxy is located and which hostnames are proxied.

Using the control panel clusters editor, add the following metadata to your cluster configuration:

| Key | Example Value | Description |
| :--- | :--- | :--- |
| **`PROXY_ADDRESS`** | `10.40.4.42` | The IP address of your NFS server. |
| **`PROXY_HOSTNAMES`** | `app1.com app2.com` | A space-separated set of hostnames using the proxy. |

{{< figure src="/images/egress-proxy/cluster_metadata.png" width="60%" alt="Example" >}}

If your cluster is managed, adding metadata will cause automatic deployment. For an un-managed cluster, a manual deployment is necessary.

## 2. Verification
After a web server is initialized, use SSH connect to open a terminal window and run a command to verify the proxy is used. Use any of the hostnames that you specified in `PROXY_HOSTNAMES`. The output of the command should show the address of the NFS server and a successful status code.

```bash
$ curl -sw '%{remote_ip} %{response_code}\n' -o /dev/null https://app1.com/
10.40.4.42 200
```
---
# How to Contact Support
URL: https://docs.webscale.com/docs/getting-started/support/
Description: A guide to contacting Webscale Support



There are multiple ways to contact Webscale Support if you have queries or need help resolving an issue with Webscale products.

- Normal support requests, such as information or changes to production systems, should be sent to [support@webscalenetworks.com](mailto:support@webscalenetworks.com).
- Critical requests, such as issues that are impacting your users’ ability to checkout or purchase items through your site, should be sent to [critical@webscalenetworks.com](mailto:critical@webscalenetworks.com).

There is also a [Support Portal](https://support.webscalenetworks.com). Log in to the Support Portal to open new tickets or manage existing tickets.

## Sign up for the Support Portal
The first time you visit the Support Portal you must sign up. When you visit the portal, you see the following page where you can sign up or login:
{{< figure src="/images/support-portal/signup0.png" width="75%" alt="Support portal login page" >}}

To sign up for a new account, click the **Create an Account** button. Enter your personal, address and login information and then solve the captcha challenge.

{{< figure src="/images/support-portal/signup1.png" width="25%" alt="Support portal personal information during signup" >}}
{{< figure src="/images/support-portal/signup2.png" width="25%" alt="Support portal address information during signup" >}}
{{< figure src="/images/support-portal/signup3.png" width="25%" alt="Support portal dashboard" >}}

Once submitted, an account will be created and you will be redirected to the [Support Portal](https://support.webscalenetworks.com).

{{< figure src="/images/support-portal/dashboard.png" width="75%" alt="Support portal login page" >}}
## Create a new ticket via the Support Portal
Once logged in, open new support tickets from the **Contact Us** tab.  Fill in all the mandatory details. Relevant **Subject**, **Description** and **Case Priority** should be selected for the tickets to get routed to the appropriate queue for faster response. You can also attach screenshots or log files while creating a ticket.

{{< figure src="/images/support-portal/contact-us.png" width="75%" alt="Support portal 'Contact Us' form" >}}

### Setting case priority
{{< figure src="/images/support-portal/case-priority.png" width="75%" alt="Support portal case priority select" >}}

Choose the appropriate **Case Priority** for the ticket from the drop-down:
- **1 - Critical - Business Impacting**: Issues that are impacting customers’ ability to checkout or purchase items through the site. This can also be logged by sending an email to [critical@webscalenetworks.com](mailto:critical@webscalenetworks.com).
- **2 - Non-Critical**: Issues pertaining to information or any configuration changes on production/staging/development environments.
- **3 - Query - Technical**: Queries related to features and functionality of the Webscale product.
- **4 - Query - Non Technical**: Any non-technical queries, e.g. something related to the Support Portal or Slack.
- **5 - Scheduled Activity**: Request for any scheduled task like upgrading or downgrading a service, pre-scale in/out for clusters, patching, etc.

## Updating an existing ticket
Check and update existing tickets from the **My Tickets** section under the profile icon in the upper right corner.

{{< figure src="/images/support-portal/update-existing-ticket.png" width="25%" alt="Update existing tickets" >}}

This will show the list of all the tickets which are resolved, currently being worked on or are waiting for a response either from you or Webscale Support.

{{< figure src="/images/support-portal/list-tickets.png" width="75%" alt="My tickets" >}}

When a ticket is in progress, click **Ticket Reference Number** or **Subject** in the list to update the ticket or read the response from Webscale Support.

{{< figure src="/images/support-portal/reply-or-close-ticket.png" width="75%" alt="Reply or close ticket" >}}

### Add a user to a ticket
If another user in your organization should be sent a copy of the ticket, you can do so by adding the user.

{{< figure src="/images/support-portal/add-user-to-ticket.png" width="25%" alt="Add user to ticket" >}}

You can also edit the ticket properties, if needed.

{{< figure src="/images/support-portal/ticket-properties.png" width="75%" alt="Ticket properties" >}}

## Resolve a ticket
If your issue has been resolved, you can choose to mark the ticket as such. Once a ticket is resolved, you can choose a satisfaction rating. If the same issue recurs, the same ticket can be re-opened within 30 days from the ticket closure date.

{{< figure src="/images/support-portal/resolve-ticket.png" width="75%" alt="Resolve ticket confirmation" >}}
{{< figure src="/images/support-portal/resolved-ticket.png" width="75%" alt="Resolved ticket" >}}

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Frequently Asked Questions](/docs/faq/)
---
# How to Complete the Onboarding Questionnaire
URL: https://docs.webscale.com/docs/getting-started/onboarding/
Description: A guide to completing the onboarding questionnaire



A new application needs to be integrated to the Webscale network in order to be added properly. This integration is customized to each application for the best performance. To ensure the integration is done accurately,  Webscale's onboarding team must gather some information about the application. To ensure communication flows properly, some information about your organization is also needed. Webscale's onboarding team will send you a spreadsheet to gather this information.

## Contact and company info

To ensure that Webscale's team can communicate with your organization, Webscale requires some contact information.
{{% alert title="Note:" %}}
_Some or all of the following may be required, depending upon your organization._
{{% /alert %}}

#### Contact information

Webscale asks for a primary contact, a technical contact, and an after hours or escalation contact. These contacts do not necessarily need to be different parties. Please supply the following information for each of these contacts:

- Name
- Email address
- Main contact number
- Cell phone number
- Business or availability hours
- Time zone

You may also want the following user accounts created for the above contacts on Webscale's system so they can more easily contact us. Please provide the email addresses for any users you want these accounts created for.

- Slack user account
- Support portal account

Once you have admin access to the Webscale Control Panel, you can also [invite users](/docs/how-tos/general/user-roles/) to the portal.

#### Third party and system integration information

Oftentimes, applications integrate with third party systems to add functionality required by your organization. If your application has these integrations, Webscale may require the following contact information for them:

- Company name
- Primary contact
- Developer/s
  - Is this developer familiar with the application's code base?

#### Billing contact

Webscale will also need to be able to contact your organization's billing or accounting department. Please provide the following information for this contact:

- Name
- Phone number
- Email address

#### Corporate information

Webscale requires the following information for legal and taxation purposes.

- Complete legal name of your company/organization.
- Address, including City, State, and ZIP code.
- Corporate website address.
- Main corporate phone number.

## Current hosting environment

Webscale's onboarding team will need information about the application's current hosting environment so the team can integrate the application to the Webscale network.

{{% alert title="Note:" %}}
_Some or all of the following may be required, depending upon your application's configuration._
{{% /alert %}}

#### Network and architecture descriptions

The following information about the application's network and architecture will help the onboarding team access the application.

- Current hosting company.
- Is an architecture diagram available?
- Whitelisting/blacklisting: are there any currently whitelisted or blacklisted addresses? If so, please provide those.
- Current database type? (RDS, MySQL, etc.)
- Origin IP address: the current IP address of the application.

#### Current server SSH access

If your team requires that Webscale copy your files to the Webscale Networks environment, then SSH access will be required. The SSH user can be one created specifically for Webscale, or it can be an existing user account.

- IP Address: the IP address used for SSH connections to the application.
- Username: the SSH username for Webscale to use.
- Password: the SSH user's password.
- Is the user `root` or does the user have `sudo` access? We recommend creating a `sudo` user.
- Is a public key requested from Webscale? <!-- I don't understand this question, I will get clarification -->
- If your application is firewalled and Webscale's IP address needs to be whitelisted, please add `35.165.34.92` to the whitelist so we can access it.

#### Current DNS information

Please share the current DNS provider's name here.

##### Complete list of domain names

In addition to the above DNS information, Webscale will also need to know all the current domain names in use by the application, including:

- Main site: is this using the apex domain, i.e. no subdomain or `www`?
- Alternate sites
- Blogs
- Microsites
- Development or staging sites
- All others

#### Staging/dev environment

If you have a staging or development environment for your application, please share that information accordingly.

- What domain or domains are needed for staging?
- If the staging site uses a separate domain from the main site (i.e. is not a subdomain, etc.), do you have an SSL certificate for this domain?
- Are there different `MAGE_RUN_CODE` or `MAGE_RUN_TYPE` settings you'd like to set? (Magento only)
- Are there any SSH keys you'd like to add or remove?
- What is the document root you expect on the staging environment?
  - Would you like to keep this document root the same or change it to something else?

#### SSL certificates

To ensure no interruption of the site's `https` settings, please share information about the SSL certificates in use.

- What type of SSL certificates are currently in use? (Wildcard, EV, SAN, etc.)
- Who is the SSL provider?

## Magento application

If your application is built on Magento, Webscale will require some information about the Magento application and it's environment.

#### Magento

Please share the following Magento-specific details:

- Magento version
- Magento admin
- Magento "from" email address
- Magento search
- Full page cache (entirepise, Lesti, Amasty, etc.)

#### Email

Webscale also requires information about the application's email server and environment. For example, Webscale needs to know whether you are using your own hosted email server (`localhost`), or a plugin or third party service such as SendGrid or Mailchimp.

- How do you send marketing emails?
- How do you send transaction or order confirmation emails?
- Are emails sent directly from the data server?
- Is the web server in use Apache or Nginx?
- What web server modules are you using?

#### PHP version

What PHP version is the application currently using?

#### WordPress

If you have a blog or additional site using WordPress, please share the following details:

- WordPress public URL.
- WordPress installation path.

#### CDN

Will you be using Webscale's CDN provider (CloudFront)?

#### External system integrations

If your application integrates with external systems, please share information about those as well.

- Warehouse
- Inventory
- ERP
- CRM
- Shipping
- Other
- Who is the payment processor?
- Are there any modules that require a static IP address?
- Any additional applications setup? (examples: New Relic, Elastic Search, SOLR, etc.)

#### Load testing

Please let the Webscale team know if you plan on doing load testing of the application.

#### Code deployment method

If your team uses a version control system to deploy the codebase of the application, please share that information here. For example, if your team uses Git and GitHub, please share the access information for the repository.

## Webscale, AWS, and GCP environment

All of the information on these tabs will be completed by Webscale to document the details of the architecture that Webscale will provision.

## Conclusion

Now that you've provided these details to the Webscale onboarding team, they will start getting your application onboarded and integrated with the Webscale Network.

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Frequently Asked Questions](/docs/faq/)
---
# Webscale Go-live Process
URL: https://docs.webscale.com/docs/getting-started/go-live/
Description: A brief explanation of the go-live process for your application on Webscale's network



## What to expect from the go-live process
Once your application has been fully integrated into Webscale’s network and tested, it will be ready to go live. Before the final go-live process can take place, there are some checks both you and Webscale will do to ensure a smooth transition.

## Before go-live
Before the site goes live, perform some testing to ensure the application works as expected. You will also work with Webscale’s team to ensure that important information and dates are agreed on to avoid any miscommunication, possible delays, or unforeseen downtime of the application.

### Pre-live checklist
The pre-live checklist is a list of items that the Webscale team will complete before the go-live date. In some cases, they may require some assistance from you on certain steps in the pre-live checklist. If this is the case, the Webscale team will reach out to you to let you know.

### Testing
- Test your code deployment process. Your codebase needs to be properly deployed prior to go-live.
- Test that every action that every user can take on the site will work appropriately from all allowed IP addresses. This testing includes the following:
  - General browsing on the site (both as a customer logged in or out).
  - Proceed through the entire checkout process (start to finish) for all types of products.
  - Ensure that all product and category pages load as expected.
  - Every user who uses the Admin panel should test that their functionality works properly for themselves.
  - Developers must test their code deployment process.
- Webscale will contact you via the dedicated Slack channel once the pre-live checklist is complete.

### Other important steps

- You and Webscale will work out the go-live date and time. Any changes should be communicated as soon as possible. We request at least 3 business days advance notice to schedule resources for the go-live and to complete the pre-live checklist.
- Between now and the go-live date, Webscale will stay in communication with you on the status of the transition. This may be done via Slack or email, or both.
- To avoid excessive downtime, please lower the TTL on your DNS zone prior to go-live day. Webscale will communicate the proper DNS records to use when launching the site.
- Your deployment team will want to familiarize themselves with [Webscale CLI](/docs/how-tos/advanced/webscale-cli/), Webscale’s command-line tool.

## The go-live process

Within three days of the date you’ve chosen for the site to go live, Webscale will complete a dry-run of the site and perform some testing. There are also some steps you will have to take. This process includes some or all of the following tasks, depending on your application:

- Is maintenance mode available on the current site? Webscale offers maintenance mode for the application once it’s on our network, and this will be set during testing. You can and should upload a custom maintenance page in your Webscale control panel. See [How to Set Maintenance Mode](/docs/how-tos/general/maintenance/#upload-a-microsite) for instructions.
- Webscale will ensure there is a final sync/copy of the application’s database, media, and any NFS (network file system).  This can also be done by you or your development partner.
- You and Webscale both will then test the site using a temporary hostname.
- At least one day prior to go-live day, lower the TTL on the DNS zone for the domain the application will use. Once the TTL change has propagated, the new host record entry can be added as it will now propagate more quickly, reducing any downtime. Make this change at the pre-arranged time.
- The last step is to unset the Webscale maintenance page and then test the site using the domain instead of the temporary hostname.

## Completion

Once the site has gone live, you'll receive a confirmation email from Webscale Networks. This email will contain a link you can click to schedule a meeting with the customer success team. In this meeting you can discuss how the process has gone so far and what to expect from the Webscale customer success team. The email also contains important information about [contacting support](/docs/getting-started/support/) and using the Webscale Control Panel.

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Frequently Asked Questions](/docs/faq/)
---
# How to Deploy Your Code on Webscale
URL: https://docs.webscale.com/docs/getting-started/deploy/
Description: Information on how to deploy your code and details about how the deployment process works.



The Webscale deployment process is a modern [CI/CD](https://en.wikipedia.org/wiki/CI/CD) pipeline, with your code being managed by source control and then deployed using [Docker](https://www.docker.com/) containers. This removes the majority of downtime associated with deploying the code for a new application or website. In the past, it was necessary to set your Magento application to maintenance mode while the build processes were run, often resulting in downtimes of at least 1-2 hours. Using this modern CI/CD pipeline not only ensures little to no downtime, but also allows you to fix any problems with the site much more quickly.

{{% alert title="Note:" %}}
Since this deployment process is new, not all existing customer implementations are designed to use it. Customers who are on the legacy deployment method and would like to redeploy using the Docker-based deployment method outlined here should reach out to their Webscale account manager to discuss their options.
{{% /alert %}}

This deployment process uses Docker containers and the [AWS ECR](https://aws.amazon.com/ecr/) container registry to take all of the code compilation steps that are part of the build process and add them to a Docker deployment script, which uses the code from your source control to build an image. This Docker image build can be run on a staging server while the production site is still live. This allows your team to test and verify the new deployment without impacting your customers. Once you’ve verified that the site builds properly, you can deploy the same image to production quickly, while all of the site’s assets are simultaneously deployed, resulting in near-zero downtime. Since a new build can be done quickly with a Docker script, any problems with the production site can be quickly resolved by simply rolling back to an older Docker image stored in the container registry.

{{% alert title="Note:" %}}
Docker container images deployed on Webscale are deployed as `read-only`, to help ensure the stability and integrity of the production environment. Any code changes or testing should be done using a Docker image on a staging environment. Once the image has passed your testing, you can then deploy it to production, replacing the current production environment. Since this deployment process uses containers, there is little to no downtime as part of the process because the build has already been verified.
{{% /alert %}}

{{% alert title="Warning" color="warning" %}}
These steps are a general outline that applies in most situations. Your situation may differ depending upon the configuration of your application and its implementation. If so, more specific details will be provided during the onboarding process.
{{% /alert %}}

## Build process

1.	Webscale will authorize OAuth access to the AWS account for your Git repository (either [GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/) or [GitLab](https://gitlab.com/)).
2.	Upon a push into your Git repo, `codebuild` will build a container image with your code.
    - This process uses the Dockerfile to create the container image (a default Dockerfile template can be provided, if required). **Note**: Future images will have a "commit ID" tag by default - this comes from the Git repository.
3.	Once the container is built using the Dockerfile, the container is pushed to AWS ECR.
4.	ECR runs a vulnerability scan on the container.

## Deployment process

During onboarding, Webscale will grant you access to a deployment system via SSH that is specific to the environment to which you want to deploy. Run these commands in that environment (i.e., production or staging). The following procedure provides instructions for deployment for a staging environment. In the example, the commit id is "abc123" and Git branch name is "m2stage."

{{% alert title="Note:" %}}
You may need to upgrade your environment if you don't see any Git branch tags [*branch-branchname*]. Please let us know if this is the case.
{{% /alert %}}

### To deploy in a staging environment

SSH into the deployment system and run the following commands:

1. Run `list-images`.
    - Find the container that you want to deploy in the list.
    The images are sorted from oldest to newest with the oldest image at the top, so that the latest built image is at the bottom.
2. If you know your commit ID, run `tag-by-commit [commit id] staging` to tag the image as ready to deploy.

    -OR-

    If your environment supports tagging by branch, run `tag-by-branch [branch name] staging`
3.	Run the deployment script: `run-deploy-and-cleanup`

**Example**

```
$ list-images
"sha256:250eab59befa478121d87a06adf2745b32ceb97166d7d1fc99800785feada144": [
    "branch-m2dev",
    "commit-xyzasdf",
	"staging"
]
"sha256:035dbb834079c8103c4193ce4c6ac1609d1c2f7fdf9556635770f83dbb4e5e30": [
    "branch-m2stage",
    "commit-abc123",
]

$ tag-by-commit abc123 staging
OR
$ tag-by-branch m2stage staging

2021-08-08T08:08:08 [*docker tag*] Assigning tag staging to image [commit(abc123) digest(sha256:abcxyz456)].

$ run-deploy-and-cleanup

Waiting for servers to verify...complete
New cluster example-env-b is live. Waiting 30 seconds before cleaning up old cluster example-env-a

Deleting old servers
Done
```

## Definitions

- **Docker container**: A standard unit of software that packages code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
- **Container image**: A lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
- **Dockerfile**: A text document that contains all the commands a user could call on the command line to assemble an image.
- **Container registry**: A collection of repositories made to store container images.
- **OAuth**: An open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
- **Git**: A distributed version-control system for tracking changes in any set of files, originally designed for coordinating work among programmers cooperating on source code during software development.

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Frequently Asked Questions](/docs/faq/)
- [Dockerfile Reference](https://docs.docker.com/engine/reference/builder/)
---
# Webscale Application Architecture
URL: https://docs.webscale.com/docs/overview/architecture-overview/
Description: A Brief Overview of the Application Architecture managed by Webscale



Webscale manages (and optionally, hosts) applications running on hyperscale cloud providers with its established architecture guidelines. This document provides insight into the Application architecture managed by Webscale.

We deploy the code to a centralized server where it's then horizonally scaled across multiple servers based on configuration set by the customer. This collection of servers is also known as an Application Cluster. Several commands help manage this sync process and the symbolic links that allow all application servers to log to the centralized server, also called a _dataserver_.

## Definitions:

#### Dataserver
This is the centralized database and content server. It hosts an NFS (network file system) file share for static content and several [Redis](https://redis.io/) datastores that are memory-based fast caches. Magento cache, full page cache, and sessions use the Redis datastores. The dataserver is also the primary location for hosting the code. When you update your code, Webscale syncs it to the application server. Cron is also normally hosted here. In some architectures, the database and data server may be separated into different servers for increased efficiency. The database may also have a replica in another region/zone, mirroring the database contents to ensure business continuity.

#### Application server/Web server
This is the distributed, auto-scaling part of your application environment. It hosts the web server and the PHP portions. We use symbolic links inside the `/var/www/sitename` directory (also known as the _document root_) structure to point to directories hosted on the NFS (network file system) share. This way the application can share static content without having to sync huge amounts of data from the dataserver to the application server. This also allows logging directories within Magento or other applications to log code-related errors to a centralized, non-transient location.

#### Webscale data plane/ADC/Proxy
These are all synonyms for the Webscale platform component that “fronts” your application infrastructure. (ADC is an acronym for *application delivery controller)*. The Webscale data plane sits between your application and the internet, functioning as a reverse proxy, managing and protecting traffic accessing the application. It can do many things - load balancing, web application firewall, caching, and more. It also has a powerful DIY policy engine called **Web Controls**. A common use case that we enable through **Web Controls** is to protect your admin login pages by blocking traffic from all but the whitelisted addresses.

## Separation of responsibilities

There are two distinct spheres of responsibility, although there is overlap in some areas. Webscale is responsible for infrastructure, and you, the Webscale customer, are responsible for code. Overlap comes into play when it’s related to cron jobs, Apache settings, and PHP settings on the web servers.

Code is the PHP core of the site, including the interactions of code with the MySQL database. There are lots of interactions of code with infrastructure, but the Webscale staff are not PHP programmers, so we can only help up to a point. Code also includes images, documents, and other static assets. Static content usually goes on the network drive so that it doesn’t have to be synced to every web server created.

Infrastructure is the “backend hardware” of the site. Yes, your site is virtualized, but all that virtual stuff is designed to be a virtual representation of some bit of hardware that could be physically manifested outside the cloud—for example, servers, disks, RAM, server software, and network.
{{% alert title="Note:" %}}
The overlap is extensive, but rest assured, we do the best we can to help when we have sufficient experience and knowledge of your code deployment.
{{% /alert %}}
## Code deployment layout

In the webscale environment, there are typically two separate disks that hold code.

The first is `/var/www/www.site.net`.

{{% alert title="Note:" %}}
This directory is exactly what you would expect it to be.  It contains all the workings and contents of the site.
{{% /alert %}}

The second is `var/www/shared/www.site.net`.

{{% alert title="Note:" %}}
This is the network shared file system. We place static content and certain log files here. Since it mounts to each web server at startup, it allows Magento or Wordpress logs to be written back to the dataserver and be easily accessible. This magic is possible because we use symbolic links from the first directory that points to the second directory.
{{% /alert %}}

For example, we set up `/var/www/www.site.net/var` to point to `/var/www/shared/www.site.net/var`.

The symbolic link is then replicated by the sync process to the web server so that it is consistent across a cluster. We can also use this for upload directories to ensure that any upload to any web server is immediately available across the cluster. Other links include images or other large media files. We like to sync as little as possible to the web server so that it can quickly start when needed.

There are a couple of Webscale specific commands that are very useful in this environment.  The two most common are ACS and webscale-cli which are documented on our website on the [Webscale CLI Reference Guide](/docs/how-tos/advanced/webscale-cli/).

## Deployment best practices

1. Use the `www-upload` user for deployment. Use the command `sudo -iu www-upload` to switch to this user.
2. To fix any permission issues on the dataserver run `sudo webscale-cli deploy permissions`.
3. To fix any permission issues on the web node, run `sudo webscale-cli deploy app_permissions`.
4. To check for a sync issue and to ensure that sync is working run `acs sync && acs status -w && acs sync-status`.

## Accessing your servers

As a customer, you usually would not need to access any web server, as they are transient, and we forward logs to the dataserver.

We control access to the dataserver with ssh or secure shell. We strictly enforce public key authentication as passwords are too easily compromised. As such, we add any customer login to a list of users that can use `sudo` to become `www-upload`, the primary web content owner. You also need `sudo` to run the two Webscale CLI commands mentioned above.

## Webscale Control Panel

A vital window into your website is the [Webscale Control Panel](https://control.webscale.com/).

The Webscale Control Panel allows you to view or take action on different aspects of your application, including but not limited to:
- Monitor traffic
- View security policies
- Analyze performance
- Troubleshoot errors
- Configure the Webscale services available to the application (such as setting up PHP whitelisting and blacklisting, for example)

### Tips

PHP whitelisting and blacklisting is important to protect your site from common PHP hacks. You usually would blacklist all PHP scripts, and then whitelist the scripts you know are used in your site. You can and should [set up a whitelist](/docs/how-tos/security/whitelist/) for your Magento admin page, and [block all other IP addresses](/docs/how-tos/security/blacklist/).

You can also use the control panel to put your site into [maintenance mode](/docs/how-tos/general/maintenance/) when you need to work on it.

Please explore the [Webscale control panel](https://control.webscale.com/) to become familiar with it.

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [How to Contact Support](/docs/getting-started/support/)
- [Frequently Asked Questions](/docs/faq/)
---
# The Webscale Control Panel Dashboard
URL: https://docs.webscale.com/docs/overview/dashboard/
Description: A Brief Overview of the Webscale Control Panel Dashboard




The dashboard is the home page of the [Webscale Control Panel](https://control.webscale.com) and is displayed when you first log in. The dashboard contains links to other important areas of the control panel and includes some essential information about your Webscale account and applications.

{{< figure src="/images/account-dashboard.png" alt="Webscale Control Panel Dashboard" >}}

### Main Navigation

The main navigation bar contains a dropdown menu at the name of the current account - this allows you to choose from the accounts you have with Webscale if you have more than one. Next to this is the <i class="fas fa-cog" aria-hidden="true"></i> gear, which is where you will find the following links:

|   |   |
|---|---|
| {{< figure src="/images/gear-menu.png" alt="Gear Menu" >}}  | <ul><li>**Account Settings**: Click here to go to the control panel page to adjust account settings.<br /><br /></li><li>**Legacy UI**: Click here to be taken to the legacy control panel.<br /><br /></li><li>**Documentation <i class="fas fa-external-link-alt" aria-hidden="true"></i>**: Click here to open the Webscale Documentation in a new window.<br /><br /></li><li>**Get support**: Click here to view information about how to contact Webscale Support.<br /><br /></li><li>**Logout**: Click here to log out of the control panel. </li></ul> |

{{% alert title="Note:" %}}
Depending upon the access level of your user account, you may not have all of these options.
{{% /alert %}}

The main navigation menu also contains a timer icon and a <i class="fa fa-user" aria-hidden="true"></i> user icon.
- Click on the timer icon to show the **Task Monitor**. This shows any tasks that have run in the last 24 hours, and whether they completed or not. Click the **Zoom** button to go to the full **Task Monitor** page.
- Click on the <i class="fa fa-user" aria-hidden="true"></i>  user icon to visit the user preferences page. Use the **User Editor** to make changes to the current user, and click the **Access Keys** tab to view existing API keys or create a new one.

### Page Contents

Under the main navigation bar, the page has several boxes displayed. From left to right, top to bottom, these are:

|   |   |
|---|---|
| **Data transfer** <img width=250/>  | Displays the data transfer used by the current account. Contains a daily total and the total for the current month. |
| **Sessions** <img width=250/> | Displays a count of user sessions for the current account. Contains a daily total and the total for the current month. |
| **Page Views** <img width=250/> | Displays the page views for the current account. Contains a daily total and the total for the current month. |
| **Billing** <img width=250/> | Displays the current amount due, the due date, and the amount and date the last payment was received. |
| **Events** | Displays the most recent events reported for the account. Click the **Zoom** button to get more detailed information about these events. <br />On the Events page, you can also click **Search** to search the events, and click **Time** to view events for a specific time frame. Click **Dashboard** on the upper left to return. |
| **Application Boxes** | The top of the application box contains the hostname of the application, as well as icons indicating the status of the application's SSL and the Webscale Shield. Mouse over either icon for more information.<br />Click the **Zoom** button to go to the control panel for the application. Click the <i class="fa fa-ellipsis-v" aria-hidden="true"></i> 3 vertical dots to display a menu showing many of the options that are also on the application’s control panel. {{< info-mark >}}More details about this menu are [below](#application-box-actions-menu). The application boxes also display some information about your applications at a glance, including: <ul><li>**Webscale hostname**</li><li>**Uptime**</li><li>**Scaling**, **Requests per Second**, and **Response Time** graphs showing the last 24 hours.</li><li>Whether the application is currently running or not.</li><li>Cache miss rate displayed as a percentage.</li><li>Servers displayed as icons - mouse over each icon to get the IP address of the server.</li></ul> |
<hr />

#### Application Box actions menu

Click the <i class="fa fa-ellipsis-v" aria-hidden="true"></i> 3 vertical dots on the upper right corner of the Application box to display the actions menu for your Application.

|   |   |
|---|---|
| {{< figure src="/images/application-actions-menu.png" alt="Application Box actions menu" >}}  |<ul><li>**Diagnose**: Click here to go to the diagnose panel for the application. <br />Displays diagnostic information about the application. <br />**Probes** shows the current status of some application metrics. <br />**Events** will display the events log page for the application.<br /><br /></li><li>**Edit**: Click here to go to a panel to edit various settings for your application. <br /><br /></li><li>**Advanced Edit**: Click here to go to the advanced edit panel for the application.<br /><br /></li><li>**Traffic Viewer**: Click here to go to the [Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/).<br /><br /></li><li>**CSP Reports**: Click here to go to the [CSP Reports](/docs/how-tos/web-controls/csp-create/#viewing-the-content-security-policy-logs) viewer. <br /><br /></li><li>**View Configuration**: Click here to view the current configuration details for this application.<br /><br /></li><li>**Flush Caches**: Click here to [flush the site and Pagespeed caches](/docs/how-tos/advanced/site-cache/).<br /><br /></li><li>**Start maintenance**: Click here to put the application into [maintenance mode](/docs/how-tos/general/maintenance/).<br /><br /></li><li>**Enable shield**: Click here to enable [shield mode](/docs/how-tos/general/shielding/). <br /><br /></li><li>**Whitelist**: Click here to view and configure the [whitelist](/docs/how-tos/security/whitelist/). <br /><br /></li><li>**Blacklist**: Click here to view and configure the [blacklist](/docs/how-tos/security/blacklist/). </li></ul> |

## Further Reading
- [How to Invite Users](/docs/how-tos/general/user-roles/)
- [How to View Webscale Application Server Information](/docs/how-tos/advanced/appserverinfo/)
- [How to Manage Web Controls](/docs/how-tos/web-controls/webcontrols_manage/)
- [Webscale FAQ](/docs/faq/)
---
# Basic How-To Guides
URL: https://docs.webscale.com/docs/how-tos/general/
Description: Guides on using basic features through the Webscale Control Panel


---
# How to Create Roles and Invite Users
URL: https://docs.webscale.com/docs/how-tos/general/user-roles/
Description: How to create roles and invite users in the Webscale Control Panel



After completing the Webscale onboarding process, you will have your own Webscale account. Access to this account is controlled via roles. By default, your new account includes a few important roles to help you get started: **Editor** and **Reader**. In general, editors will have access to view, create, modify and destroy resources in the account while readers will only be able to view those resources. A user's access in the account is determined by the roles to which they have accepted invitations. This guide details how to create your own custom roles and how to invite users to them.

Roles can be used in two separate use cases:
- [**Webscale Secure Access**](/docs/how-tos/security/secure-access/): an optional web control action used to protect parts of your applications from the general internet.
- [**Webscale API role-based access**](/docs/reference/rbac/): a user's access to the Webscale API is determined by the access described by the roles to which they have accepted invitations.

### Create a role
|   |   |
|:---:|---|
|{{< figure src="/images/roles-users/roles-menu.png" width="135px" alt="Roles Menu" >}} | 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left.<br /> Select **Roles** from the menu. |
| {{< figure src="/images/roles-users/roles-view.png" alt="Roles List" >}} | 2. Here you view existing roles on the [Roles](https://control.webscale.com/roles) page in the Control Panel. {{< info-mark >}}Predefined roles such as **Editor** and **Reader** cannot be deleted. |
| {{< figure src="/images/roles-users/roles-access.png" alt="Access" >}} | 3. For [Webscale API role-based access](/docs/reference/rbac/) roles, clicking **APIs** lists the Webscale API access this role provides.|
| {{< figure src="/images/roles-users/roles-users.png" alt="Invited users" >}} | 4. Clicking **Users** lists the users that have been invited to assume the role and whether they have accepted, declined or vacated that invitation.
| {{< figure src="/images/roles-users/create-role.png" alt="New Role Creation" >}}| 5.  Click **Role** in the lower left part of the page to create a new role. In the wizard that appears, you'll be walked through the steps to configure the role.
|| 6. Roles are fully customizable. It is recommended you set an informative name and description to ease the management of multiple roles.
|| 7. [Webscale API roles](/docs/reference/rbac/) roles can be configured to apply their access to the account in which the role is created or in the sub-accounts of that account, excluding the account itself. {{< info-mark >}}If your account does not have sub-accounts, select 'Current account'.  |
|| 8. You have control over prerequisites a user must satisfy in order to assume a role to which they have accepted an invitation. These prerequisites are satisfied when the user authenticates with Webscale and include whether [**multi-factor authentication**](/docs/how-tos/security/mfa/) is required and how often they are required to re-authenticate.|
| {{< figure src="/images/roles-users/roles-apis.png" alt="APIs List" >}} | 9. [Webscale API roles](/docs/reference/rbac/) roles are configured with the Webscale API access they permit and deny. The wizard allows you to target entire collections of resources (e.g. `/accounts`) or collections of sub-resources (e.g. `/accounts/{id}/invitations`). {{< info-mark >}}Additionally, you can target specific resources using the **Custom APIs** input. Once you've chosen the HTTP method, API and access, click the **+** button to add the custom API to the role configuration. API wildcards are available to you to help make specifying an API easy: for example, `/accounts/*` will match any specific account but none of its sub-resources whereas `/accounts/**` will match any specific account resource and all of its sub-resources.
| {{< figure src="/images/roles-users/create-role-invite.png" alt="New Role Creation showing invite box" >}} | 10. Lastly, invite users to the role. Confirm the changes you've made, then click **Save** to save the changes. This action creates the role, and sends invitations to any users invited to the role. {{< info-mark >}}If the user invited does not exist, this action will send an email to the user with a link to sign up. Once they complete sign-up (create a password) and log in, they will be taken to the [User Profile](https://control.webscale.com/profile) and can accept the role.|

### Invite a user to an existing role
|   |   |
|:---:|---|
| {{< figure src="/images/roles-users/roles-menu.png" width="135px" alt="Roles Menu" >}} | 1. Login to the [Webscale control panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left.<br /> Select **Roles** from the menu. |
| {{< figure src="/images/roles-users/roles-users.png" alt="Invited users" >}} | 2. On this page you see existing roles. To invite a user to the role, click the **'Users'** button for the role, then click the pencil in the upper right of the expanded panel. |
| {{< figure src="/images/roles-users/create-role-invite.png" alt="New Role Creation showing invite box" >}} | 3. Enter the user's email address, and click the **+** button. A comma-separated list of email addresses can be inputted at a single time. This will send invitations to all the added email addresses. |
|{{< figure src="/images/roles-users/invite-user-new-role.png" alt="New Role Invitation Email" >}}| 4. The user receives an email from Webscale with a link to the [User Profile](https://control.webscale.com/profile), where they can accept the role. {{< info-mark >}}If the user invited does not exist, this action will send an email to the user with a link to sign up. Once they complete sign-up (create a password) and log in, they will be taken to the User Profile and can accept the role. |
|{{< figure src="/images/roles-users/user-profile.png" alt="User Profile" >}}| 5. In the [User Profile](https://control.webscale.com/profile) the user can manage their password and their multi-factor authentication settings. The user will also see some information about their user account, such as:  <ul><li>Any existing roles and groups to which the user belongs.</li><li>The user's name.</li><li>The user's email address.</li><li>Webscale API access keys.</li></ul>{{< info-mark >}}Users can leave a role. In such an event, they must be re-invited to the role if they wish to regain access. {{< info-mark >}}If the role the user was invited to does not permit Webscale Control Panel access, the user will only have access to their User Profile. This may be the case if you only want the role to apply to the [**Webscale Secure Access**](/docs/how-tos/security/secure-access/) web control, for example.|

## Further reading
- [How to Configure Multi-factor Authentication](/docs/how-tos/security/mfa/)
- [Webscale API role-based access](/docs/reference/rbac/)
- [How to Use Webscale Secure Access](/docs/how-tos/security/secure-access/)
- [Web Controls](/docs/how-tos/web-controls/)
---
# How to Create Groups and Invite Users
URL: https://docs.webscale.com/docs/how-tos/general/groups/
Description: How to create groups and invite users in the Webscale Control Panel



# Overview
Webscale groups consolidate multiple [roles](/docs/how-tos/general/user-roles/) so they can be managed as one entity. Generally, the encapsulated roles are expected to be related in some way or share similar responsibilities, though this is not a requirement.

## Create a group
|        |   |
|---|---|
|{{< figure src="/images/groups/menu.png" width="135px" alt="Groups Menu" >}}| 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left.<br /> Select **Groups** from the menu. |
|{{< figure src="/images/groups/view.png"  alt="Groups" >}}|2. Here you view existing groups on the [Groups](https://control.webscale.com/groups) page in the Control Panel. |
|{{< figure src="/images/groups/roles.png"  alt="Roles" >}}|3. Clicking **Roles** lists the roles encapsulated by the group. |
|{{< figure src="/images/groups/users.png"  alt="Users" >}}|4. Clicking **Users** lists the users invited to assume the group and whether they have accepted, declined or vacated that invitation. |
|{{< figure src="/images/groups/new.png"  alt="Users" >}}|5. Click **Group** in the lower left part of the page to create a new group. In the wizard that appears, you'll be walked through the steps to configure the group. |
||6. It is recommended to use an informative name and description to ease the management of multiple groups. |
|{{< figure src="/images/groups/select-roles.png"  alt="Select Roles" >}}|7. Select the roles the group should encapsulate. {{< info-mark >}}Via the Control Panel, only roles configured in the current account will be listed. Via the API, any role to which the user has access can be configured.|
|{{< figure src="/images/groups/invite-users.png"  alt="Invite users" >}}|8. Lastly, invite users to the group. Confirm the changes you've made, then click **Save** to save the changes. This action creates the group and sends invitations to any users invited to the group. {{< info-mark >}}If the user invited does not exist, this action will send an email to the user with a link to sign up. Once they complete sign-up (create a password) and log in, they will be taken to the [User Profile](https://control.webscale.com/profile) and can accept the group.|
## Invite users to an existing group
|   |   |
|:---:|---|
|{{< figure src="/images/groups/menu.png" width="135px" alt="Groups Menu" >}}| 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left.<br /> Select **Groups** from the menu. |
||2. On this page you see existing groups. To invite a user to the group, click the **Users** button for the group, then click the pencil in the upper right of the expanded panel.|
| {{< figure src="/images/groups/invite-users.png" alt="Inviting a user to an existing group" >}} | 3. Enter the user's email address, and click the **+** button. A comma-separated list of email addresses can be inputted at a single time. This will send invitations to all the added email addresses. |
|{{< figure src="/images/roles-users/invite-user-new-role.png" alt="New Role Invitation Email" >}}| 4. The user receives an email from Webscale with a link to the [User Profile](https://control.webscale.com/profile), where they can accept the role. {{< info-mark >}}If the user invited does not exist, this action will send an email to the user with a link to sign up. Once they complete sign-up (create a password) and log in, they will be taken to the User Profile and can accept the group. |
|{{< figure src="/images/roles-users/user-profile.png" alt="User Profile" >}}| 5. In the [User Profile](https://control.webscale.com/profile) the user can manage their password and their multi-factor authentication settings. The user will also see some information about their user account, such as:  <ul><li>Any existing roles and groups to which the user belongs.</li><li>The user's name.</li><li>The user's email address.</li><li>Webscale API access keys.</li></ul>{{< info-mark >}}Users can leave a group. In such an event, they must be re-invited to the group if they wish to regain access. {{< info-mark >}}If the role the user was invited to does not permit Webscale Control Panel access, the user will only have access to their User Profile. This may be the case if you only want the role to apply to the [**Webscale Secure Access**](/docs/how-tos/security/secure-access/) web control, for example.|
---
# How to View Users and Remove Their Access
URL: https://docs.webscale.com/docs/how-tos/general/users/
Description: How to view users, reset their MFA, and remove their access in the Webscale Control Panel



Access to Webscale accounts are controlled via [Roles](/docs/how-tos/general/user-roles/) and [Groups](/docs/how-tos/general/groups/).  For users with admin type permissions, the Users page facilitates easy viewing of the users that have a role or group defined in an account. In addition, the Users page allows easy resetting of a user's MFA, removal of all a user's access to an account, and revoking an individual invitation from a role or group.

The table on the Users page displays information about each user: their email which functions as their unique identifier, their name, when they were created, and the last time they changed their password. Click on a user's row to display the roles and groups that user has been invited to as as well as when the invite was sent and accepted.

On the Users page within a particular account called the **Users account**, Webscale administrators can utilize four additional features: view all users across all accounts, view users with removed access, view a user's roles and groups across all accounts, and remove a user's access from all accounts.

{{< figure src="/images/users/users-page.png" width="100%" alt="Users Page">}}

## Reset a user's MFA
|   |   |
|:---:|---|
|{{< figure src="/images/users/users-navlist.png" width="135px" alt="Users Navlist" >}} | 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left. <br><br><br><br><br>2. Open the **Access Control** accordion and then select **Users** from the menu. |
| {{< figure src="/images/users/users-page.png" alt="Users Page" >}} | 3. This Users page shows users that have access to this account. |
|{{< figure src="/images/users/users-more-menu.png" alt="Users More Menu" >}} | 4. Click the more menu <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the far right of a user's row.
|{{< figure src="/images/users/users-reset-mfa-option.png" alt="Users Reset MFA Option" >}} | 5. Click the **Reset MFA** option. {{< info-mark >}}If the user is not enrolled in MFA, the Reset MFA option will be disabled with a tooltip on hover that says "No MFA enabled".|
|{{< figure src="/images/users/users-reset-mfa-modal.png" alt="Users MFA Modal" >}} | 6. Click **Reset MFA** button on the modal and observe a "MFA was reset successfully" confirmation message. {{< info-mark >}}If you do not have sufficient permissions to reset another user's MFA then a error message will be displayed.|

## Remove a user's access
|   |   |
|:---:|---|
|{{< figure src="/images/users/users-navlist.png" width="135px" alt="Users Navlist" >}} | 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left. <br><br><br><br><br>2. Open the **Access Control** accordion and then select **Users** from the menu. |
| {{< figure src="/images/users/users-page.png" alt="Users Page" >}} | 3. This Users page shows users that have access to this account. |
|{{< figure src="/images/users/users-more-menu.png" alt="Users More Menu" >}} | 4. Click the more menu <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the far right of a user's row.
|{{< figure src="/images/users/users-remove-access-option.png" alt="Users Remove Access Option" >}} | 5. Click the **Remove All Access** option. {{< info-mark >}}If the user is yourself then the Remove All Access option will be disabled with a tooltip on hover that says "Cannot remove own access". {{< info-mark >}}If you do not have sufficient permissions to remove another user's access the option will be disabled with a tooltip on hover that says "Insufficient permissions".|
|{{< figure src="/images/users/users-remove-access-modal.png" alt="Users Remove Access Modal" >}} | 6. Click the **Remove All Access to This Account** button on the modal and observe a confirmation message.|

## Revoke a user's invitation to a role or group
|   |   |
|:---:|---|
|{{< figure src="/images/users/users-navlist.png" width="135px" alt="Users Navlist" >}} | 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left. <br><br><br><br><br>2. Open the **Access Control** accordion and then select **Users** from the menu. |
| {{< figure src="/images/users/users-page.png" alt="Users Page" >}} | 3. This Users page shows users that have access to this account. |
|{{< figure src="/images/users/users-details-drawer.png" alt="Users Details Drawer" >}} | 4. Click a user's row to open a user's details drawer.
|{{< figure src="/images/users/users-trash-can.png" alt="Users Trash Can Icon to Revoke Invitation" >}} | 5. Click the trash can on the far right of a role or group row.
|{{< figure src="/images/users/users-revoke-invitation.png" alt="Users Revoke Invitation" >}} | 6. Click the **Revoke Invitation** button on the modal and observe a confirmation message.|

## Additional features within the Users account
|   |   |
|:---:|---|
|{{< figure src="/images/users/users-page-users-account-navlist.png" alt="Users Page in the Users Account with Navlist open" >}} | A set of authorized Webscale team members have access to an account that has the express purpose of managing permissions of all users across all accounts. This account is called the Users account. With the Users page within the Users account, these authorized team members gain access to **four additional features**.
| {{< figure src="/images/users/users-page-users-account.png" alt="Users Page in the Users Account" >}} | The only page within the Users account is the Users page. <br><br>**Additional Feature 1:** View all users across all accounts. In contrast, in all other accounts only users who have an invitation for a role or group from that particular account can be viewed. |
|{{< figure src="/images/users/users-access-removed.png" alt="Users Access Removed" >}} | **Additional Feature 2:** View all users that have had access at any point including those that have had their access removed. In contrast, in all other accounts only users that currently have access can be viewed. <br><br>Check the checkbox "Include Users Whose Access Has Been Removed". |
|{{< figure src="/images/users/users-across-accounts.png" alt="Users Roles Across All Accounts" >}} | **Additional Feature 3:** View all roles and groups a particular user has across all accounts. In contrast, in all other accounts only the roles and groups defined in that particular account can be viewed. <br><br>Click a user's row to view all their roles and groups across all accounts. |
|{{< figure src="/images/users/users-remove-access-all-accounts.png" alt="Users Remove Access Across All Accounts" >}} | **Additional Feature 4:** Remove all access across all accounts. In contrast, in all other accounts access can only be removed from that account. <br><br>1. Click the more menu <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the far right of a user's row. <br><br>2. Click the **Remove All Access** option. <br><br>3. Click the **Remove All Access** button on the modal and observe a confirmation message.

## Further reading
- [How to Configure Multi-factor Authentication](/docs/how-tos/security/mfa/)
- [How to Create Roles and Invite Users](/docs/how-tos/general/user-roles/)
- [How to Create Groups and Invite Users](/docs/how-tos/general/groups/)
- [Webscale API role-based access](/docs/reference/rbac/)
---
# Working with Labelers
URL: https://docs.webscale.com/docs/how-tos/general/labelers/
Description: How to create and edit Labelers



A labeler applies a label to all future logs that match the labeler’s configuration.  These labels can be a powerful tool in analyzing logs. For example, you can create a labeler using a complex filter query, allowing you to simply search for that label in the traffic viewer and refine the query as needed.

{{% alert title="Note:" %}} These labels differ from labels applied using Web Controls in that the labels are applied to the logs just before they are written, instead of when the request is received.{{% /alert %}}

{{< figure src="/images/labelers/labelers-page.png" width="100%" alt="Labelers Page">}}

## Create a Labeler
|   |   |
|:---:|---|
|{{< figure src="/images/labelers/labelers-navlist.png" width="135px" alt="Labelers Navlist" >}} | 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left. <br><br><br><br><br><br><br>2. Select **Labelers** from the menu. |
| {{< figure src="/images/labelers/labelers-page.png" alt="Labelers Page" >}} | 3. This **Labelers** page shows the existing labelers in a table. |
| {{< figure src="/images/labelers/labelers-new-button.png" alt="Labelers New Labeler Button" >}} | 4. Click the **New labeler** button. |
| {{< figure src="/images/labelers/labeler-new-name-description.png" alt="Labelers New Labeler Name and Description Fields" >}} | 5. Add a **Name** and **Description** that will help explain the labeler's purpose when viewed in the labelers table.|
{{< figure src="/images/labelers/labeler-new-label.png" alt="Labelers New Labeler Label Field" >}} | 6. Add the **Label** itself that will help explain the label's purpose when filtering or analyzing the labeled logs|
{{< figure src="/images/labelers/labeler-new-applications.png" alt="Labelers New Labeler Application Field" >}} | 7. Choose **Select by application name** or **Select by application label** to determine the contents of the next field which, in turn, configures which applications should be labeled. <br>{{< info-mark >}}An application label can be created and added to an application in **Edit** application on the **General** page. |
{{< figure src="/images/labelers/labeler-new-log-type-filter.png" alt="Labelers New Labeler Log Type and Filter Fields" >}} | 8. Select which **Log type** should be labeled of the available log types, and then create the **Filter** that decides which logs of that log type should be labeled. <br>{{< info-mark >}}The filtering functionality here is the same as the filter in Traffic Viewer. It is recommended to use Traffic Viewer to create a filter that will filter the desired logs, and then paste that filter here.
| {{< figure src="/images/labelers/labeler-reset-create-buttons.png" alt="Labelers New Labeler Page" >}} | 9. Click **Create Labeler**, and observe a confirmation message. The **Reset** button clears the field values.

## Edit a Labeler
|   |   |
|:---:|---|
|{{< figure src="/images/labelers/labelers-navlist.png" width="135px" alt="Labelers Navlist" >}} | 1. Login to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> in the upper left. <br><br><br><br><br>2. Select **Labelers** from the menu. |
| {{< figure src="/images/labelers/labelers-page.png" alt="Labelers Page" >}} | 3. This **Labelers** page shows the existing labelers in a table. |
| {{< figure src="/images/labelers/labelers-more-menu.png" alt="Labelers More Menu" >}} | 4. Click the more menu <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the far right of a labelers's row. |
| {{< figure src="/images/labelers/labelers-edit-option.png" alt="Labelers Edit Option in More Menu" >}} | 5. Click the **Edit Labeler** option. |
| {{< figure src="/images/labelers/labelers-edit.png" alt="Labelers Edit Labeler Page" >}} | 6. Edit the Labeler, click **Update Labeler**, and observe a confirmation message. The **Reset** button will reset the labeler to the form's state when it was navigated to and therefore it is disabled when no edits have occurred.<br><br>7. Click **Back to Labelers** to navigate back to the Labelers page. |

## Further reading
- [Building Traffic Viewer Filters](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
---
# Configuring General Application Settings
URL: https://docs.webscale.com/docs/how-tos/general/app-general-settings/
Description: Configure general application settings through the Webscale Control Panel



The **General** page enables you to modify basic settings for an application, including its name, labels, default hostname, and aliases.

## Access the General page

### To access general application settings

Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select **Edit**.

{{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

-or-

On your application page, click the **Actions** menu icon and select **Edit**.

{{< figure src="/images/access_edit_action_menu.png" alt="Select edit application" >}}

The **General** page displays.

 {{< figure src="/images/general_page.png" alt="General page" >}}

## Change application name

### To change an application name

1. Enter a new name in the **Application name** field.
2. Click **Apply**.

## Labels

A label is an alternative name for the application that Webscale uses in features, such as monitors, to designate the application.

{{% alert title="Note:" %}}
Label names must be in lower case and can include numerals.
{{% /alert %}}

### To add a label

1. Click the **Add labels** link.
2. Enter a label name in the **Add labels** field and click **Add**.</br>
    A label displays to the left of the **Add labels** link.
3. Click **Apply**.

### To delete a label

1. Click the **x** on the label to delete.
2. Click **Apply**.</br>
    It no longer displays to the left of the **Add labels** link.

## Change application default hostname

If you have more than one alias for an application, you can specify any of them as the application's default hostname.

### To change the application hostname

1. Choose another hostname in the **Default hostname** drop-down list.
2. Click **Apply**.

## Application aliases

### To add an application alias

1. Enter an alias.
2. To include the alias in the CloudFront CDN installation, select the **CDN** check box for it. Otherwise, configuring Webscale CDN will not include creating the alias in CloudFront, too.
3. Click **Add**. The alias displays in the list of application aliases.

### To delete an alias

1. Click the **x** for the alias. It no longer displays in the list.
2. Click **Apply**.

## Further reading
- [Working with Monitors](/docs/how-tos/advanced/monitors/)
---
# Managing Maintenance Mode
URL: https://docs.webscale.com/docs/how-tos/general/maintenance/
Description: Manage maintenance mode for your application using the Webscale Control Panel



Maintenance mode provides the ability to temporarily replace your application with a simple microsite in order to perform maintenance or otherwise make changes to your site. A microsite displays to inform users that the site is in maintenance mode and temporarily unavailable.

Microsites are standalone websites that display for your application. A microsite package file (also known as a microsite file) contains the files for one or more microsites. There are five microsites that can display for standard usages, including maintenance mode. For more information about microsites, see [Working with Microsites](/docs/how-tos/advanced/microsite/).

Maintenance Web Controls are Web Controls that run during maintenance mode. Through them, Webscale executes a set of pre-defined actions. Depending on configuration, there may be conditions that must be met before the actions can execute.

There is a default maintenance Web Control that manages the microsite that displays during maintenance mode. You can optionally add, edit, and delete maintenance Web Controls.

The **Maintenance web controls** page enables you to define the one-page microsites that Webscale will serve by selecting the microsite files that contain these standard microsites. It also enables you to access maintenance Web Controls.

## Topics

- [Start and stop maintenance mode](#start-and-stop-maintenance-mode)
- [Standard microsites](#standard-microsites)
- [Access the Maintenance web controls page](#access-the-maintenance-web-controls-page)
- [Default microsite file](#default-microsite-file)
- [Replace associated microsite file](#replace-associated-microsite-file)
- [Maintenance Web Controls](#maintenance-web-controls)
    - [Default maintenance Web Control](#default-maintenance-web-control)
    - [Edit maintenance Web Controls](#edit-maintenance-web-controls)
    - [Add maintenance Web Controls](#add-maintenance-web-controls)
    - [Delete maintenance Web Controls](#delete-maintenance-web-controls)

## Start and stop maintenance mode

You can place your application in and out of maintenance mode through the Webscale Control Panel.

#### To start maintenance mode

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Start maintenance**.

   {{< figure src="/images/maintenance/maintenance_start_select.png" align="left" width="95%" alt="Select Start Maintenance" >}}

   -or-

   On your application page, click the **Actions** menu icon and select **Start maintenance**.

   {{< figure src="/images/maintenance/maintenance_actions_start.png" align="left" width="45%" alt="Select Start Maintenance" >}}

2. In the confirmation box, click **Ok**.
  {{< figure src="/images/start-maintenance.png" alt="Start maintenance mode" >}}

3. Click **Ok**. A maintenance mode page displays for site users.

    {{< figure src="/images/maintenance/default_maintenance_mode_page.png" align="left" width="50%" alt="Default maintenance page" >}}

#### To stop maintenance mode

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select **Stop maintenance**.

   {{< figure src="/images/maintenance/maintenance_select_stop.png" alt="Select Stop Maintenance" >}}

   -or-

   On your application page, click the **Actions** menu icon and select **Stop maintenance**.

   {{< figure src="/images/maintenance/stop_maintenance_action_menu.png" alt="Select Stop Maintenance" >}}

2. In the confirmation box, click **Ok**.
  {{< figure src="/images/stop-maintenance.png" align="left" width="85%" alt="Stop maintenance mode" >}}

3. Click **Ok**. The maintenance mode page no longer displays.

#### Automatically start and stop maintenance mode

When using [Managed Deployments](/docs/how-tos/advanced/managed-deployments/), you can configure any applications associated with a cluster to automatically enter and exit maintenance mode during deployments of that cluster. Do this by checking the **Enable maintenance during deployments** checkbox during cluster setup. In the event of a deployment failure, the application(s) will remain in maintenance mode.

## Standard microsites

Following are the files names and usage of the standard microsites, which are all one-page microsites.

- `captcha.html`: Displays for user challenges
- `index.html`: Displays in lieu of all standard microsite files except for `captcha.html`
- `maintenance.html`: Displays when your application is in maintenance mode
- `queued-reject.html`: Displays when Webscale rejects a deferred proxy request because the proxy request queue is full
- `timeout.html`: Displays when a request times out

For more information about standard microsites, see [Standard microsites](/docs/how-tos/advanced/microsite/#standard-microsites) in [Working with Microsites](/docs/how-tos/advanced/microsite/).

### General usages

A maintenance Web Control designates and serves the maintenance mode microsite unless no maintenance Web Controls exist.

There is also a microsite package file that is selected on the **Maintenance web controls** page and associated with it. The microsites that this file contains determine the pages that automatically display for rejected queued proxy requests and timeouts. If there is a request Web Control with the Challenge user action, it uses the captcha microsite for the file. If the microsite file does not include a `captcha.html` file, the default Webscale captcha displays.

If there are no maintenance Web Controls, Webscale uses a microsite from the microsite file selected on the page as the maintenance mode page.

For more information on captcha microsites, see [Captcha pages](/docs/how-tos/advanced/microsite/#captcha-pages) in [Working with Microsites](/docs/how-tos/advanced/microsite/). For more information on creating a request Web Control with the **Challenge User** action, see [Protecting Your Site with a Captcha](/docs/how-tos/web-controls/captcha-action/).

## Access the Maintenance web controls page

After you access the **Maintenance web controls page**, you can work with the microsite file associated with the page and maintenance Web Controls.

#### To access the Maintenance web controls page

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Edit**.

    {{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/access_edit_action_menu.png" alt="Select edit application" >}}

2. On the sidebar menu, click **Maintenance**. The **Maintenance web controls** page displays.

    {{< figure src="/images/maintenance/access_maintenance_web_controls_page.png" alt="Access Maintenance web controls page" >}}

## Default microsite file

Webscale provides a microsite default file that contains the standard microsite files. (Though the microsite file names are different for this default microsite file, the same microsite displays for maintenance mode, rejected queued requests, and timeouts.)

Initially, the default file is selected for the **Maintenance web controls** page and default maintenance Web Control. You can replace the default microsite file with another uploaded microsite file. The microsite files for the page and maintenance Web Control can be different.

## Replace the associated microsite file

You can replace the microsite file selected for the **Maintenance web controls** page, which might be the default microsite file, with a new uploaded file. The new file can contain microsites that are specific to each condition and customized for your business. For instance, the timeout microsite could include wording referencing a timeout and your branding.

A microsite file might have only one HTML file. If it is named `index.html` and located at the root directory of the package file, the single file will display for both rejected queued proxy requests and timeouts. If you use it for a maintenance Web Control to serve as the maintenance mode page, or there are no maintenance Web Controls, the index file microsite will function as the maintenance mode page.

#### To replace a microsite file

1. In the **Maintenance web controls** page, select the new microsite file from the **Microsite** drop-down menu.

   {{< figure src="/images/maintenance/maintenance_select_microsite_file.png" align="left" width="100%" alt="Select microsite file" >}}

2. To preview a microsite that the microsite file contains:</br>
    a. Click **Preview**.</br>
    b. In the preview dialog box, select the microsite from the microsite file drop-down menu.</br>

   {{< figure src="/images/maintenance/maintenance_preview_microsite.png" align="left" width="75%" alt="Preview microsite file" >}}

    c. Click **Close** to return to the **Maintenance web controls** page.
3. Click **Apply**.

   {{< figure src="/images/maintenance/maintenance_apply_new_microsite.png" align="left" width="100%" alt="Apply replacement microsite file" >}}

## Maintenance Web Controls

Web Controls consist of configured rule sets that match individual request conditions. Based on the conditions, Web Controls automatically execute a set of pre-defined actions. When one or more specified conditions are met, Webscale applies all configured actions to the request.

The maintenance Web Controls only operate during maintenance mode. Just as with other types of Web Controls, you can edit conditions and actions and add and delete these Web Controls.

If you have more than one maintenance mode web control, they behave the same way that multiple request web controls do. This includes the order in which actions execute.

The primary purpose of maintenance Web Controls is to serve the maintenance mode page during maintenance mode.

For more information on creating Web Control conditions and actions, see [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/). For information on working with more than one Web Control, see [Managing Web Controls](/docs/how-tos/web-controls/webcontrols_manage/).

### Default maintenance Web Control

The default maintenance Web Control has the following pre-configured actions.

- Set response header: Response header will be set to: `Pragma: no-cache`
- Set response header: Response header will be set to: `Cache-Control: private, no-cache`
- Serve (final): Request will be served with microsite resource `Default Microsite` with a status code of `503` specified at path `maintenance.html`

    {{< figure src="/images/maintenance/default_maintenance_web_control.png" align="left" width="100%"width="75%" alt="Default maintenance Web Control" >}}

Until you change these settings or delete the default maintenance Web Control, whenever you put your site into maintenance mode, Webscale executes the above actions in the following way.

- Sends responses with headers that instruct browsers to not cache the maintenance mode page
- Displays the maintenance mode page from the specified microsite file with the HTTP 503 status code (service unavailable). As the final action, these steps will always take place after all other maintenance Web Controls actions run.

For more information on HTTP request headers and status codes, see [HTTP Headers and Status Codes](/docs/reference/http-headers/).

### Edit maintenance Web Controls

When you edit a maintenance Web Control, you can modify its name, descriptions, and its conditions and actions. You can also add new conditions and actions.

You can choose for Webscale to display a different maintenance mode page than the default one when editing the maintenance Web Control that serves this page.

#### To edit a maintenance Web Control

1. In the **Maintenance web controls** page, click the <i class="fa fa-angle-right" aria-hidden="true"></i> icon for the maintenance Web Control.

    {{< figure src="/images/maintenance/maintenance_web_control_select.png" alt="Select maintenance Web Control" >}}

2. Click the **Edit** <i class="fas fa-edit" aria-hidden="true"></i> icon.

    {{< figure src="/images/maintenance/maintenance_web_control_edit_icon.png" alt="Click the Edit icon" >}}

3. In the sections for configuring maintenance Web Controls that display under the **Edit maintenance web control** heading, optionally, replace the name and description of the maintenance Web Control.

    {{< figure src="/images/maintenance/edit_maintenance_web_controls_sections.png" alt="Edit maintenance web controls sections" >}}

4. To add a condition:</br>
    a. Select click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.</br>
    b. In the condition drop-down menu, select a condition. The settings for the condition display.</br>

      {{< figure src="/images/maintenance/maintenance_web_control_condition_menu.png" alt="Edit maintenance web controls sections" >}}

    c. Configure the condition, using your setting information.</br>
    d. Click **Done**.

    {{< figure src="/images/maintenance/maintenance_add_condition_done.png" alt="Add maintenance Web Control condition" >}}

    e. Click the **Done** button that is located to the right of the **Edit maintenance web control** heading.</br>

    {{< figure src="/images/maintenance/maintenance_add_condition_2nd_done.png" alt="Click Done" >}}

    f. Click **Apply**.

    {{< figure src="/images/maintenance/maintenance_apply_condition.png" alt="Click Apply" >}}

5. To edit a condition:</br>
    a. Click the **Edit** <i class="fas fa-edit" aria-hidden="true"></i> icon for the condition.</br>

    {{< figure src="/images/maintenance/maintenance_click_edit_condition.png" alt="Click Edit" >}}

    b. Modify the setting.</br>
    c. Click **Done**.</br>

    {{< figure src="/images/maintenance/maintenance_edit_condition_first_done.png" alt="Click Done" >}}

    d. Click the **Done** button that is located to the right of the **Edit maintenance web control** heading.</br>

    {{< figure src="/images/maintenance/maintenance_edit_condition_click_done.png" alt="Click Done" >}}

    e. Click **Apply**.

    {{< figure src="/images/maintenance/edit_maintenance_condition_apply.png" alt="Click Apply" >}}

6. To delete a condition:</br>
    a. Click the **X** icon for the condition. The condition entry no longer displays.</br>

    {{< figure src="/images/maintenance/maintenance_delete_condition_x.png" alt="Click x icon to delete" >}}

    b. Click the **Done** button that is located to the right of the **Edit maintenance web control** heading.</br>

    {{< figure src="/images/maintenance/maintenance_edit_condition_click_done.png" alt="Click Done" >}}

    c. Click **Apply**.

    {{< figure src="/images/maintenance/maintenance_apply_delete_condition.png" alt="Click Apply" >}}

7. To add an action:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add action**.</br>
    b. In the **Type** drop-down menu, select an action. The settings for the action display.</br>

      {{< figure src="/images/maintenance/maintenance_web_control_type_menu.png" alt="Select action" >}}

    c. Configure the action, using your setting information.</br>
    d. Click **Done**.

    {{< figure src="/images/maintenance/create_action_first_done.png" alt="Click Done" >}}

    e. Click the **Done** button that is located to the right of the **Edit maintenance web control** heading.</br>

    {{< figure src="/images/maintenance/create_maintenance_action_second_done.png" alt="Click Done" >}}

    f. Click **Apply**.

    {{< figure src="/images/maintenance/create_maintenance_action_apply.png" alt="Click Apply" >}}

8. To edit an action:</br>
    a. Click the **Edit** <i class="fas fa-edit" aria-hidden="true"></i> icon for the action.</br>

    {{< figure src="/images/maintenance/edit_maintenance_web_control_action.png" alt="Click Edit" >}}

    b. Modify the setting.</br>
    c. Click **Done**.</br>

    {{< figure src="/images/maintenance/edit_maintenance_action_first_done.png" alt="Click Done" >}}

    d. Click the **Done** button that is located to the right of the **Edit maintenance web control** heading.</br>

    {{< figure src="/images/maintenance/edit_maintenance_action_second_done.png" alt="Click Done" >}}

    e. Click **Apply**.

    {{< figure src="/images/maintenance/edit_maintenance_action_apply.png" alt="Click Done" >}}

9. To delete an action:</br>
    a. Click the **X** icon for the action. The action entry no longer displays.

    {{< figure src="/images/maintenance/maintenance_web_control_click_x_action.png" alt="Delete maintenance web controls action" >}}

    b. Click the **Done** button that is located to the right of the **Edit maintenance web control** heading.</br>

    {{< figure src="/images/maintenance/delete_maintenance_action_second_done.png" alt="Click Done" >}}

    c. Click **Apply**.

    {{< figure src="/images/maintenance/delete_maintenance_action_apply.png" alt="Click Apply" >}}

10. When you have finished editing the maintenance Web Control, click the **Done** button that is located to the right of the **Edit maintenance web control** heading.

    {{< figure src="/images/maintenance/edit_maintenance_web_control_done.png" alt="Click Done" >}}

11. Select the **Enabled** checkbox to enable the maintenance Web Control if it is not already enabled.
12. Click **Apply**.

    {{< figure src="/images/maintenance/edit_maintenance_web_control_apply.png" alt="Click Apply" >}}

{{% alert title="Tip:" %}}
To replace the maintenance mode page:
1. For the maintenance Web Control that serves the maintenance mode page, click the **Edit** <i class="fas fa-edit" aria-hidden="true"></i> icon.
2. Click the **Edit** <i class="fas fa-edit" aria-hidden="true"></i> icon for the **Serve** action.
3. Select a different microsite file and path.
4. If the path to the maintenance mode page is different, select the correct path.
5. Click **Done**.
6. When you have finished editing the maintenance Web Control, finalize and apply the changes.
{{% /alert %}}

### Add maintenance Web Controls

You might want to create a maintenance Web Control to configure a series of conditions and actions to occur in addition to preventing site usage and displaying the maintenance mode page.

For instance, a new maintenance Web Control condition could provide site access for specific internal users.

#### To add a maintenance Web Control

1. In the **Maintenance web controls** page, click **Add a maintenance control**.
2. Enter a name for the maintenance Web Control.
3. Optionally, enter a description.
4. To add a condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.</br>
    b. In the condition drop-down menu, select a condition. The settings for the condition display.</br>
    c. Configure the condition, using your setting information.</br>
    d. Click **Done**.
5. To add an action:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add action**.</br>
    b. In the **Type** drop-down menu, select an action. The settings for the action display.</br>
    c. Configure the action, using your setting information.</br>
    d. Click **Done**.
6. When you have finished configuring the maintenance Web Control, click the **Done** button that is located to the right of the **Edit maintenance web control** heading.
7. Select the **Enabled** checkbox.
8. Click **Apply**.

{{% alert title="Tip:" %}}
To add a maintenance Web Control to enable internal users to access your site during maintenance mode:
1. Through the **Create address set** dialog box, create an address set with the IP addresses of the internal users. For more information on how to add an address set, see [Create address sets](/docs/how-tos/general/address-sets/#create-address-sets) in [Working with Address Sets](/docs/how-tos/general/address-sets/).
2. When creating the maintenance Web Control, add an **IP address not in set** condition and select the address set that you have created.
The serve action (and other actions) will only execute for the site user if their IP address is not in the set.
{{% /alert %}}

### Delete maintenance Web Controls

If you delete all maintenance Web Controls, Webscale will use the `maintenance.html` file for the microsite file that is selected on the **Maintenance web controls** page. Or, if there is no `maintenance.html` file, it will use the `index.html` file.

#### To delete a maintenance Web Control

1. In the **Maintenance web controls** page, click the <i class="fa fa-angle-right" aria-hidden="true"></i> icon for the maintenance Web Control to delete.
2. Click the **X** icon for the maintenance Web Control.
3. In the confirmation box, click **Ok**.
4. Click **Apply**. The maintenance Web Control no longer displays.

## Further reading

- [Working with Files](/docs/how-tos/general/files/)
- [Working with Microsites](/docs/how-tos/advanced/microsite/)
- [Protecting Your Site with a Captcha](/docs/how-tos/web-controls/captcha-action/)
- [Web Controls](/docs/how-tos/web-controls/)
- [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
- [Managing Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
---
# Working with Address Sets
URL: https://docs.webscale.com/docs/how-tos/general/address-sets/
Description: Create and edit address sets through the Webscale Control Panel



An address set is a list of IP addresses that Webscale manages and uses in features like [Trusted Proxies](/docs/how-tos/advanced/trusted-proxies/), [Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/), [Web Controls](/docs/how-tos/web-controls/webcontrols_create/), and [Allowed](/docs/how-tos/security/whitelist/) and [Blocked](/docs/how-tos/security/blacklist/) lists. For instance, you must select address sets for the trusted proxies to enable and use the Trusted Proxies feature.

All applications for the account can use the address sets. The **Address sets** tab of the account settings page enables you to work with address sets through the **Webscale Control Panel** page. Each address set is listed in the table as a separate entry.

{{< figure src="/images/address-sets/address_sets_tab.png" align="left" width="100%" alt="Address sets tab on the account settings page">}}

## Topics

- [Address set types](#address-set-types)
- [Create address sets](#create-address-sets)
- [Delete address sets](#delete-address-sets)
- [Add IP addresses to address sets](#add-ip-addresses-to-address-sets)
- [Edit or remove individual IP addresses from address sets](#edit-or-remove-individual-ip-addresses-from-address-sets)

## Address set types

There are several types of address sets, which correspond to different ways of retrieving IP addresses. Following are the address set types.

- **Combined**: Comprised of other address sets
- **Domains**: Determines and retrieves its IP addresses via a DNS lookup of specified domains
- **Dynamic**: Added with only a name and optional description (defining the *add to address set* Web Control action adds IP address, which can change over time)
- **json-file**: Contains IP addresses that are populated from a JSON file fetched from a specified URL
- **Manual**: Contains IP addresses that users manually add and update
- **Text file**: Contains IP addresses that are populated from a text file fetched from a specified URL

You cannot delete combined, domains, json-file, and text file address sets. You can view the details of one of these address sets by clicking the information icon <i class="fa fa-info-circle" aria-hidden="true"></i> to the right of the address set.

{{% alert title="Note:" %}}
For json-file address sets, you can also specify a [JMESPatch expression](https://jmespath.org/) to parse and filter the json object for addresses. Additionally, you can specify a fetch interval to configure the frequency (in seconds) of auto-updates from the URL.
{{% /alert %}}

{{% alert title="Note:" %}}
For text file address sets, you can also specify an interval (in seconds) to configure the frequency of auto-updates from the URL.
{{% /alert %}}

For information on dynamic address sets, see [Using Web Controls for Rate Limiting](/docs/how-tos/advanced/rate-limiting/).

## Create address sets

After you select one of the address set types, the **Create address set** dialog box adds fields specific to the type.

{{< figure src="/images/address-sets/create_address_set_procedure.png" align="left" width="100%" alt="Procedural steps for creating address sets">}}

### To create an address set

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Address sets**.
3. On the **Address sets** tab, click **Create set**.
4. On the **Create address set** dialog box, select the address set type.
5. Enter a name and description.
6. Add information or upload files specific to the address type:
   - Add IP addresses or domains
   - Upload a json or text file
<br/>
<br/>
7. To change an IP address expiration date, choose another date on the slider and click **Add**.

   {{% alert title="Note:" %}}
   By default, the address set's expiration slider is set to **Never**. It will not expire unless you specify an expiration time or delete the address set. You can change the default by sliding to a pre-selected time. The expiration times are incremented by days, weeks, months, and a year from the time that you added the IP address.
    {{% /alert %}}

8. Click **Save**.

## Delete address sets

You can delete manual address sets as well as dynamic address sets that are not in use.

### To delete an address set

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. Select **Address sets** on the sidebar menu.
3. Click the **X** icon at the end of the address set entry.

   {{< figure src="/images/address-sets/delete_address_set.png" align="left" width="100%" alt="Delete an address set">}}

4. Click **Ok** in the confirmation box.

    {{< figure src="/images/address-sets/delete_confirm.png" align="left" width="100%" alt="Delete confirmation box">}}

## Add IP addresses to address sets

You can add IP addresses to manual address sets.

### To add an IP address

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Address sets**.
3. On the **Address sets** tab, click the edit icon <i class="fas fa-edit" aria-hidden="true"></i> for the manual address set.

   {{< figure src="/images/address-sets/select_edit_address_sets.png" align="left" width="100%" alt="Choose to edit an address set">}}

4. In the dialog box for the address set, enter an IP address, optional description, and click **Add**.

   {{< figure src="/images/address-sets/edit_address_set.png" align="left" width="100%" alt="Edit an address set">}}

5. Click **Apply** to add the IP address. Or, **Revert** if you do not want to add it.
6. Repeat the steps if you want to add another IP address.

## Edit or remove individual IP addresses from address sets

You can edit and remove existing IP addresses for manual address sets. When you edit an IP address, you can modify its description and expiration date.

### To edit or remove an IP address

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Address sets**.
3. On the **Address sets** tab, click the edit icon <i class="fas fa-edit" aria-hidden="true"></i> for the address set.
4. In the dialog box for the address set, to edit an IP address set:<ol type='a'>
    <li>Click the edit icon <i class="fas fa-edit" aria-hidden="true"></i> for an IP address.</li>
    <li>Modify its description and/or expiration date.</li>
    <li>Click <strong>Update</strong>.</li>
    <li>Click <strong>Apply</strong>.</li>
</ol>

   &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;-or-

   &nbsp; &nbsp;&nbsp; &nbsp; &nbsp;To delete an IP address, click the delete icon <i class="fas fa-trash-alt" aria-hidden="true"></i> for the IP address.

## Further reading
- [Configuring Trusted Proxies](/docs/how-tos/advanced/trusted-proxies/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/)
- [Web Controls](/docs/how-tos/web-controls/)
- [Editing the Allowlist](/docs/how-tos/security/whitelist/)
- [Editing the Blocklist](/docs/how-tos/security/blacklist/)
- [Configuring Web Controls for Rate Limiting](/docs/how-tos/advanced/rate-limiting/)
---
# Working with Files
URL: https://docs.webscale.com/docs/how-tos/general/files/
Description: Work with files using the Webscale Control Panel



Through the **Files** page, you can work with files. After you upload files for your account, they are available for all of the account applications.

The CloudEDGE Workers and microsite features both use uploaded files. Information specific to working with handler and microsite files, including previewing files, is located in [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/) and [Working with Microsites](/docs/how-tos/advanced/microsite/).

CloudEDGE Workers enables you to easily extend your application's functionality through custom JavaScript without changing your application code. For more information about the CloudEDGE Workers feature, see [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/).

A microsite is a standalone website that displays for your application.

## Topics

- [File requirements](#file-requirements)
- [List of files](#list-of-files)
- [Getting started](#getting-started)
- [Access the Files page](#access-the-files-page)
- [Upload files](#upload-files)
- [Work with uploaded files](#work-with-uploaded-files)
  - [Downloading](#download-file)
  - [Replacing](#replace-file)
  - [Editing file details](#edit-file-details)
  - [Deleting](#delete-file)

## File requirements

Files must conform to the following requirements with the exception of the maximum file size for handler and microsite files.

- .zip, .tar, or .tar.gz file format
- Maximum file size: 50 MB
- For microsites, links to assets must be relative (pages can also contain links to external websites).

{{% alert title="Note:" %}}
You can also upload WAF rules, bootstrap, and Geodb files for use by legacy functionality. For WAF rules, you can use Web Controls to perform the same functions.
{{% /alert %}}

## List of files

On the **Files** page, each file lists in the **Files** panel with the following characteristics.

- Name
- Version
- Creation and updated times

If there is a description and label, they will also display for the file. When you select a file, the file version and contents display in the **Content** panel. When you select a file in the **Content** panel, it displays in the **Preview** panel.

There is a system default file that is named "Default Microsite" unless you change its name. For more information about this file, see [Microsites files](/docs/how-tos/advanced/microsite/#standard-microsites) in [Working with Microsites](/docs/how-tos/advanced/microsite/).

{{< figure src="/images/microsites/microsites_files_page_panels.jpg" align="left" width="100%" alt="Panels on the Files page" >}}

## Getting started

1. On the **Webscale Control Panel** page, [access](#access-the-files-page) the **Files** page.
2. If the file does not already display in the list of files, [upload](#upload-files) it.
3. Select a file in the files panel.<br>
   An icon panel that enables you to download, replace, change details, and delete the file displays to the right of the **Updated** column for the file.
4. After the above steps, continue with the remaining steps for the relevant operation.

## Procedures

The following procedures pertain to all features that involve uploading and working with files. You can use the **Files** page to perform the following operations.

## Access the Files page

#### To access the Files page

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Files**.

    {{< figure src="/images/files/select_files.png" align="left" width="95%" alt="Files sidebar option">}}

## Upload files

#### To upload a file

1. On **the Webscale Control Panel** page, select **Files** on the sidebar menu.
2. In the **Files** page, click **Create file**.

    {{< figure src="/images/microsites/microsites_create_file.jpg" align="left" width="100%" alt="Click create file to upload" >}}

3. In the **Upload File** dialog, click **Choose File**.

    {{< figure src="/images/microsites/microsites_upload_file.jpg" align="left" width="65%" alt="Choose file" >}}

4. Select a file on your computer and click **Open**, or drag-and-drop it to the **File** box.
5. Optionally, enter a new name and/or label for the file. (The label only applies to this version of the file.)
6. Select the file type.
7. Optionally, enter a file description and label.
8. Click **Save**.<br>
  A new entry displays in the **Files** page list.

{{% alert title="Note:" %}}
If you cannot save a file, make sure that it meets the [file requirements](#file-requirements).
{{% /alert %}}

## Work with uploaded files

For uploaded files, you can perform the following operations.

- [Downloading](#download-file)
- [Replacing](#replace-file)
- [Editing file details](#edit-file-details)
- [Deleting](#delete-file)

{{< figure src="/images/files/selected_file_icons.png" align="left" width="90%" alt="File operations icons" >}}

### Download file

#### To download a file

Click the **Download** icon <i class="fas fa-download" aria-hidden="true"></i> in the icon section.

### Replace file

#### To replace a file

To replace the file with a new version of the same file or a different file, perform the following procedure.

1. Click the **Upload new file version** icon <i class="fas fa-upload" aria-hidden="true"></i>.
2. In the **Upload Version** dialog, click **Choose File**.
3. Optionally, enter a label for this verson of the file.
4. Click **Save**.
5. Click **Update** to use the uploaded file as your current version.
6. If you click **Cancel**, Webscale will upload the file and increment the version number but not use it as your current version.

    {{< figure src="/images/files/files_new_version_save.png" align="left" width="100%" alt="Save new file version" >}}

{{% alert title="Note:" %}}
When you upload a new file, you can upload a new version or a different file.
{{% /alert %}}

### Edit file details

#### To edit file details

  1. Click the **Edit file** icon <i class="fas fa-edit" aria-hidden="true"></i>. In the **Edit** dialog, you can:
      - Change the file name
      - Update the currently used version of the file
      - Optionally, enter a new description or update an existing one.
  2. Click **Save** when you are finished editing the details.

      {{< figure src="/images/files/files_edit_dialog.png" align="left" width="70%" alt="Edit dialog" >}}

### Delete file

#### To delete a file

  1. Click the **Delete file** icon <i class="fas fa-trash-alt" aria-hidden="true"></i>.
  2. Click **Ok**.<br>
  The file will no longer display in the **Files** page list.

### Preview files

There are differences in previewing files for CloudEDGE Workers and microsites.

For more information on previewing handler files, see [Preview handler files](/docs/how-tos/CloudEDGE/handlers_workers/#preview-handler-files) in [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/).


For more information about previewing microsites, see [Preview microsites](/docs/how-tos/advanced/microsite/#preview-microsites) in [Working with Microsites](/docs/how-tos/advanced/microsite/).

## Further reading

- [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/)
- [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/)
- [Working with Microsites](/docs/how-tos/advanced/microsite/)
---
# How to View Events
URL: https://docs.webscale.com/docs/how-tos/general/events/
Description: How to view events in the Webscale Control Panel



The **Events Viewer** will show recent events that have taken place for your application on the platform, and some information about those events.

{{% alert title="Note:" %}}
The events displayed will differ depending upon the privileges of the Control Panel [user role](/docs/how-tos/general/user-roles/).
{{% /alert %}}

## View Events
To view events, log in to the [Webscale Control Panel](https://control.webscale.com) and click the three bars <i class="fa fa-bars" aria-hidden="true"></i> on the upper left, then select **Events** from the menu. From here you will see a list of events on the left. To see more information about a specific event, click the event in the list. The right pane will show the information, including the following:

- Event title, short description, and time stamp.
- Information on the event including **Subject**, **Type**, **Severity**, **User**, and **Remote IP**. Some of this information may not be relevant, depending upon the event type.

## Search in Events

You can also search the events for a particular word or string if you want to find a specific event, or display events only within a specific time window.

### Search
- Click the **Search** button on the upper right.
- Enter your search term, then press enter or click the magnifying glass.
- If there are matches they will be highlighted on the screen, and you can click on the <i class="fa fa-chevron-up" aria-hidden="true"></i> or <i class="fa fa-chevron-down" aria-hidden="true"></i> buttons to cycle through the results.

### Time window
- Click the **Time** button on the upper right.
- Here you can enter a duration. Choose from 5 min, 1 hr, 3 hr, 6 hr, 24 hr, or custom. If you choose custom, input the start and end date and time. To set the end time to now, click the toggle **Ending Now**.
- When ready, click the **Submit** button to display the results.

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Viewing Reports](/docs/how-tos/general/reports/)
- [How to Enable Notifications](/docs/how-tos/general/notifications/)
- [How to Contact Support](/docs/getting-started/support/)
- [Frequently Asked Questions](/docs/faq/)
---
# Events Logs Attributes
URL: https://docs.webscale.com/docs/how-tos/general/events-logs-attributes/
Description: Detailed information about Events logs attributes



The account **Events** page enables you to view events information for all account applications. The **Events** section on the **Webscale Control Panel** page displays recent events for the applications.

You can also view events for a specific application through the application's **Events** page. The **Events** section on the application dashboard displays recent application events.

For more information on viewing events, see [Viewing Events](/docs/how-tos/general/events/).

The following table provides Events logs attribute information. You can view the name, display name, and a description for each attribute.

## Events logs attributes

Name | Display Name | Description
-- | -- | --
created | Created | ISO 8601-formatted date when the event occurred
details | Details | Event information, which is dependent on the event type and specific to the particular event. For example, an event pertaining to deleting an address from an address set might generate an audit log that documents the address set contents before and after the deletion.
message | Message | Short summary of the event
remote_ip | Remote address | IP address for the user who initiated the event, if available
severity | Severity | Categorizes event impact by the `Info`, `Warning`, or `Severe` status
subject | Subject | References what the event affected
type| Type | Characterizes event specifics, such as a system update or address set deletion
user | User | User who initiated the event

## Further reading

- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Viewing Events](/docs/how-tos/general/events/)
- [Viewing Reports](/docs/how-tos/general/reports/)
---
# How to Enable Notifications
URL: https://docs.webscale.com/docs/how-tos/general/notifications/
Description: How to enable notifications for alerts in the Webscale Control Panel



You can subscribe to alert notifications in the Webscale Control Panel. These notifications provide real-time alerts to various conditions that affect site performance. Find these alert settings in the **Alert Notifications** tab under Account Settings.

## Configure Notifications
|   |   |
|---|---|
|{{< figure src="/images/account-settings.jpg" width="75%" alt="Account Settings" >}}| 1. Log in to the [Webscale Control Panel](https://control.webscale.com) and click the <i class="fa fa-cog" aria-hidden="true"></i> gear on the upper right, then select **Account Settings** from the menu.|
|{{< figure src="/images/notifications/alert-notifications.jpg" width="75%" alt="Alert Notifications" >}}| 2. Click **Alert Notifications** from the top menu bar to view the cluster information.|
|{{< figure src="/images/notifications/all-alerts.jpg" width="75%" alt="Susbcribe to All Alerts" >}}| 3. You have the option to subscribe to all alerts or just specific alerts. To subscribe to all alerts, enter the email address you want to receive the alerts in the email address box in the **All Alerts** section. Click the **Add Email** button, then click the **Save** button.|
|{{< figure src="/images/notifications/specific-alert.jpg" width="75%" alt="Subscribe to Specific Alerts" >}}| 4. If you only want to subscribe to specific alerts, enter the email address you want to receive the alerts in the email address box in the appropriate section. For example, enter your email address in the **Application Down** section to only receive notifications for Application Down events.|
|{{< figure src="/images/notifications/minimized-alerts.jpg" width="75%" alt="Minimized Alerts" >}}| 5. Any alert notifications that you haven't configured show minimized on the list. To enable these alerts, click on the alert name, then enter your email address and click the **Save** button. |
|{{< figure src="/images/notifications/delete-alert.jpg" width="75%" alt="Delete Alerts" >}}| 6. To disable alert notifications, click the **Delete** button for the email address you wish to remove from notifications. <br />{{< info-mark >}}You should not delete any `webscalenetworks` or `victorops` email addresses for any alerts as the Webscale support team uses these.|

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [How to Enable Uptime Monitoring](/docs/how-tos/general/monitoring/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Viewing Reports
URL: https://docs.webscale.com/docs/how-tos/general/reports/
Description: View reports in the Webscale Control Panel



You can access reports on your system through the main **Reports** page, including usage and performance information.

The Outbound data transfer report presents a consolidated view of the amount of outbound data transferred for your account and applications. Outbound data transfer, measured in gigabytes (GB), consists of responses from Webscale to site user requests.

(The data transfer monitor uses the same information as this report. It tracks data transfer usage for all account applications. You can configure it to generate events when it detects activity that matches or exceeds conditions that you define. This monitor can send email notifications when the events occur.)

If you have the optional application testing feature, you can view the results of your application load tests. For information about these tests, see [Application load tests](#application-load-tests).

## Topics

- [Access the Reports page](#access-the-reports-page)
- [Outbound data transfer report](#outbound-data-transfer-report)
    - [Frequency of updating data](#frequency-of-updating-data)
    - [Date range selector](#date-range-selector)
    - [Data transfer graph](#data-transfer-graph)
    - [History table](#history-table)
- [Application load tests](#application-load-tests)

## Access the Reports page

The Outbound data transfer report displays on the **Reports** page. If you have the optional application testing feature, you can access load test results reports through through this page.

#### To access the Reports page

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper-left of the screen.
2. On the sidebar menu, select **Reports**.

   {{< figure src="/images/reports/reports_access_page.png" align="left" width="100%" alt="Select Reports" >}}

    -or-

    In the **Webscale Control Page** page, click **Zoom** in the **Data transfer** section at the upper-left of the screen.

   {{< figure src="/images/reports/reports_click_zoom_data_transfer.png" align="left" width="100%" alt="Select Reports" >}}

## Outbound data transfer report

{{< figure src="/images/reports/reports_data_transfer_callouts.png" align="left" width="100%" alt="Outbound Data Transfer Report with callouts" >}}

The Outbound data transfer report on the **Reports** page presents the amount of outbound data that you have used. Based on the data range for the report, other information might display.

You can use this report to identify trends and unexpected shifts regarding your outbound data usage. It consists of a graph and table. A date range selector enables you to specify the time period for the report.

The Outbound data transfer report enables you to view outbound data for your account by:

- Day
- Cumulatively for the month
- Current or last month
- All available data

You can also view daily and monthly amounts of data per application.

Your contract might include a specified monthly amount of data for your plan. By comparing data usage during the current month against the amount of monthly outbound data for your plan, you can help prevent unexpected data transfer overage fees. For help with increasing the amount of data for your plan, contact [support](mailto:support@webscalenetworks.com).

If your contract does not include monthly data, the user interface will not reference a plan amount or overages.

To view this report, follow the procedure in [Access the Reports page](#access-the-reports-page).

{{% alert title="Note:" %}}
The **Data transfer** section of the **Webscale Control Panel** page also displays outbound data transfer for the current day and month. The daily information does not display in real-time.
{{% /alert %}}

{{% alert title="Important:" %}}
If this report shows a different amount of outbound data included in your plan than the amount in your current contract, contact [support](mailto:support@webscalenetworks.com).
{{% /alert %}}

### Frequency of updating data

The data for the current day populates the report at midnight GMT on the same day. When you view this month's report, it will display the actual data for the preceding days of the month but only projected data for the current one.

Webscale uses Greenwich Mean Time (GMT) to determine when it populates the report.

{{% alert title="Important:" %}}
For the first day of a new month, the report is empty if the current month is selected as the date range. The report displays data transfer retroactively on the second day of the month.
{{% /alert %}}

### Date range selector

The **Show** drop-down menu enables you to select a date range that defines the data that displays:

- **This month** - measured in daily increments
- **Last month** - measured in daily increments
- **This month + past 12 months** - measured in monthly increments: Enables you to view data from the same month in the current and previous year (e.g., January 2021 and 2022)
- **All** - measured in monthly increments: Displays all recorded report data

When you first view the Outbound data transfer report, the data for the current month displays. Afterwards, the selected date range is the same as it was at the end of your previous session.

{{% alert title="Note:" %}}
Recorded outbound data transfer information is available for accounts starting from November 2020.

Data broken down by application is available starting from March 2022.
{{% /alert %}}

#### To change the data range

In the **Show** drop-down menu, select another date range option.

{{< figure src="/images/reports/reports_data_transfer_show_menu.png" align="left" width="100%" alt="Date range selection menu" >}}

The report information for the specified date range displays.

### Data transfer graph

The title of the data transfer graph and type of information that displays change according to the specified date range. For the **This month** and **Last month** options, the graph is named **Cumulative data transfer**. It populates with cumulative daily data for the current or previous month.

For the **This month + past 12 months** and **All** options, the graph is named **Monthly data transfer**. It measures data by the month.

#### Current and previous month graph

If you choose to view the data for the current or previous month, the data transfer line presents cumulative data for the month in daily increments.

When you hover over a date, a tooltip shows the amount of data that you have used. If you are viewing data for the current month and the trend line is forecasting an overage, it also includes the projected cumulative overage for each day. If you are viewing past data, the tooltip includes the actual cumulative overage amounts.

#### Current month graph

For only the current month graph, a dotted trend line does not appear until the third day of the month. It projects date usage for the rest of the month based on prior usage for the month.

If your contract stipulates a data transfer amount and the current usage or trend lines surpass the **Included in plan** horizontal line, the graph will indicate this actual or projected overage with orange shading for an overage and lighter orange shading for projected overage.
In addition to cumulative current and projected data, the tooltip for the current month can include the plan data amount and dates for actual or projected overage.

{{< figure src="/images/reports/reports_data_transfer_graph.png" align="left" width="100%" alt="Data transfer graph for the current month" >}}

#### Graph for the other data ranges

The graph that displays for the **This month + past 12 months** and **All** date range options presents outbound data by the month and not cumulatively. There is a trend line for the current month but nor for previous ones. If your plan includes data, the graph and tooltip reflect it.

{{< figure src="/images/reports/report_data_transfer_graph_all.png" align="left" width="100%" alt="Data transfer graph for this month + past 12 months" >}}

### History table

If you choose to view the outbound data for the current or previous month, the left section of the **History** table presents the total amount of data for each day of the month for your account. If you select the **This month + past 12 months** and **All** date range options, the left section presents the total amount of account data by month.

The **History** table does not present cumulative data.

The right section of the table breaks down the data by application.

{{< figure src="/images/reports/reports_data_transfer_table.png" align="left" width="100%" alt="Data transfer table for this month" >}}

## Application load tests

The optional application testing feature enables you to run customized load tests to measure the performance of your system. Every time that you run a test, Webscale generates a report with the test results.

A reports page that is dedicated to load test results enables you to view all test results reports. You can access test reports through the main **Reports** page and **Application testing** page.

For more information about the application testing feature and accessing test results reports through the **Application testing** page, see [Testing Your Application](/docs/how-tos/general/app-testing/).

{{% alert title="Note:" %}}
The user interface for this feature, including the **Application testing** entry on the accounts sidebar menu, only displays if this feature is enabled.
{{% /alert %}}

#### To view an application load test

1. In the main **Reports** page, select the **Test result** option in the **Reports** drop-down menu.

    {{< figure src="/images/reports/reports_page_select_test_result.png" align="left" width="65%" alt="Select Test result option" >}}

2. In the test results reports page, select a report in the right drop-down menu under **Reports**.

    {{< figure src="/images/reports/reports_select_test_result_report.png" align="left" width="65%" alt="Select test result report" >}}

    The report displays.

    {{< figure src="/images/application-testing/app_test_report.png" align="left" width="90%" alt="Test results report" >}}

3. To return to the main **Reports** page, you can select **Outbound data transfer** in the left drop-down menu under **Reports**.

    {{< figure src="/images/reports/reports_return_to_data_transfer.png" align="left" width="65%" alt="Select Data Transfer Billing option" >}}

## Further Reading
- [Data transfer monitor](/docs/how-tos/advanced/monitors/#data-transfer-monitor)
- [Testing Your Application](/docs/how-tos/general/app-testing/)
---
# Working with Providers
URL: https://docs.webscale.com/docs/how-tos/general/providers/
Description: Manage providers through the Webscale Control Panel



Webscale uses external services, such as cloud providers and Docker registries, to provide functionality and implement features. To connect to an external service, you must create a provider. External services require authentication to access them. Each provider has a set of credentials to authenticate to the corresponding service.

You can define providers for your account through the Webscale Control Panel. After you create a provider, you can use them in blueprints for data planes and clusters. You can also use providers to implement features such as Webscale CDN.

Webscale uses blueprints to connect to and define the Webscale usage of cloud providers. Applications that are associated with a data plane are connected to the providers for their data plane. As you create blueprints, the data planes, clusters, and applications connected with the provider will display in the providers list.

Webscale supports the following public cloud service providers: Amazon, Azure, Google and CloudSigma.

Providers can also be used to store credentials to access Docker registries.

After you create a provider, it will display in your list of providers. In addition, you can edit and delete them through the **Providers** tab on the account settings page.

{{< figure src="/images/providers/providers-list.png" align="left" width="100%" alt="Providers list on the account settings page">}}

## Topics

- [Create providers](#create-providers)
- [Provider settings](#provider-settings)
    - [Amazon](#amazon)
    - [Azure](#azure)
    - [CloudSigma](#cloudsigma)
    - [Google](#google)
    - [Docker Registry](#docker-registry)
    - [Section](#section)
- [Edit providers](#edit-providers)
- [Delete providers](#delete-providers)

## Create providers

When you create a Webscale provider, enter a name and select a cloud service provider type. After you select a type, the **Add Providers** dialog box adds settings specific to it. For a provider with the Amazon EC2 type, you can enable Webscale CDN and CloudEDGE Workers.

The tables that follow this procedure contain descriptions of provider type settings. The provider type settings include your logins for the cloud service provider accounts. For help with determining the values for other settings, contact [support](mailto:support@webscalenetworks.com).

{{< figure src="/images/providers/providers_tab.png" align="left" width="100%" alt="Annotated Providers tab on the account settings page">}}

### To create a provider

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on upper left of the screen.
2. On the sidebar menu, select **Providers**.
3. On the **Providers** tab, click **Add Provider**.
4. Select the provider type.
    The settings specific to the provider type display.
5. Enter settings information.
6. Click **Save**.

## Provider settings

Following are tables that contain the settings for each provider type.

### Amazon

Name | Description | Notes
-- | -- | -- |
Region | A geographic area that contains at least two distinct physical locations (known as “availability zones”), each of which contains clustered data centers. With the distributed data centers of the availability zones, a region provides high availability for the designated area.| Required |
Access key id | Used to access your AWS account | Required |
Secret access key | Used to access your AWS account | Required |
Use elastic IP | Enables using static IP addresses | Optional |
VPC | Virtual Private Cloud. Identifies a virtual network of shared resources allocated within an Amazon Web Services (AWS) public cloud environment | Optional |
Use for CDN | Enables Webscale CDN for your provider if you also specify the AWS S3 bucket for CDN logs. After you enable CDN for the provider, you can enable this feature for all applications that use the provider. | Optional |
S3 Bucket Name | Name of the AWS S3 bucket for your Webscale CDN logs | Optional. Displays if you select the **Use for CDN** checkbox. |
Use for handlers | Enables handlers for your provider. After you enable handlers for the provider, you can create handlers for your account. | Optional |
Use for Security Monitoring | Enables AWS GuardDuty security monitoring for your provider. | Optional |
Use for Kubernetes | Creates a Kubernetes service for the provider. | Optional |
Cluster Name | Name of the Amazon EKS cluster to use when creating [Kubernetes clusters](/docs/how-tos/general/kubernetes-clusters/). The provider's region must be the region of the EKS cluster. | Optional. Displays if you select the **Use for Kubernetes** checkbox. |
Use for ECR | Creates an ECR docker registry service for the provider. | Optional |
Docker registry endpoint | The fully qualified ECR endpoint in the format: <br> `aws-account-id`.dkr.ecr.`aws-region`.amazonaws.com | Required if **Use for ECR** is checked. |
Repositories | A list of ECR repository names as they appear in AWS. | At least one is required if **Use for ECR** is checked. |

### Azure

Name | Description | Notes
-- | -- | -- |
Tenant id | Unique identifier for your Azure tenant, which represents your organization in Azure Active Directory. A tenant is automatically created when your organization signs up for a Microsoft cloud service subscription. Not an organization or domain name | Required |
Client id | Unique identifier for the application that is set up through the Azure Active Directory | Required |
Client secret | Password exclusive to the application and  authorization server | Required |
Subscription | Logical container used to provision resources in Azure | Optional |

### CloudSigma

Name | Description | Notes
-- | -- | -- |
Location | Location within a geographic area designed to provide cloud services to the area | Required |
Email address | Used to access your account | Required |
Password | Used to access your account | Required |
Use static ip | Enables using static IP addresses with the account | Optional |
VLAN| Created from one or more local area networks, a Virtual Local Area Network (VLAN) combines collections of devices into one logical network | Optional

### Google

Name | Description | Notes
-- | -- | -- |
Project ID | Unique identifier for your project, which organizes all of your Google Cloud resources | Required
Email address | Email address associated with your project | Required
Private key | Private RSA key that enables generating a token to access your Google Cloud account| Required
Network | Virtual Private Cloud (VPC) network that distributes traffic from Webscale | Required

### Docker Registry

Name | Description | Notes
-- | --| -- |
Docker Registry Endpoint | The fully qualified endpoint at which the registry is accessible. | Required. |
Public | If checked, indicates that credentials are not required to access the registry. | Optional |
Repositories | A list of repositories accessible at the endpoint specified. | At least one is required. |
Username | The username used to access the docker registry. | Required if **Public** is not checked. |
Password | The password used to access the docker registry. | Required if **Public** is not checked. |

{{% alert title="Note:" %}}
For DockerHub, the Docker registry endpoint is `index.docker.io`. DockerHub Public repository names are often prepended with `library/`. For example: `library/nginx`.
{{% /alert %}}

### Section

Name | Description | Notes
-- | -- | -- |
Account Id | An ID referencing your Section account. | Required |
API token | An API Token with access to the account provided in Account Id. | Required |
Use for CDN | Enables Webscale CDN for your provider. After you enable CDN for the provider, you can enable this feature for all applications that use the provider. | Optional |
Webscale Owned | Prevents unauthorized users from managing this provider. | Optional |

## Edit providers

{{% alert title="Warning:" %}}
A provider holds the credentials Webscale uses in your cloud account. Changing its credentials or region can break the applications and clusters that use it. Contact [support](mailto:support@webscalenetworks.com) before you change one of those fields.
{{% /alert %}}

### To edit a provider

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Providers**.
3. On the **Providers** tab, click the **Edit** button for the provider.

    {{< figure src="/images/providers/providers_select_edit.png" align="left" width="100%" alt="Select Edit for a provider">}}

4. In the **Edit provider** dialog box, modify settings.
5. Click **Save**.

### Delete providers

You cannot delete providers used in blueprints. To delete a provider in use, discard any blueprints that include the provider before deleting it.

{{% alert title="Warning:" %}}
Deleting a provider, which defines the relationship between your Webscale account and cloud service, can result in serious problems. Proceed with caution and contact [support](mailto:support@webscalenetworks.com) before deleting a provider.
{{% /alert %}}

### To delete a provider

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on upper left of the screen.
2. On the sidebar menu, select **Providers**.
3. On the **Providers** tab, click the **Edit **button for the provider.
4. In the **Edit provider** dialog box, click **Delete**.
5. To confirm deleting the provider, click **Yes**.

    {{< figure src="/images/providers/providers_delete_confirm.png" align="left" width="100%" alt="Select Edit for a provider">}}

## Further reading
- [Creating Clusters](/docs/how-tos/general/clusters/)
---
# Creating Clusters
URL: https://docs.webscale.com/docs/how-tos/general/clusters/
Description: Create clusters through the Webscale Control Panel



A cluster is a collection of servers or containers that can be used to scale an application horizontally. Webscale supports both Virtual Machine (VM) based clusters as well as Amazon Elastic Kubernetes Service (EKS) clusters.
In order to create a cluster, you must first add your provider via the **Providers** tab. For more information, check out [Working with Providers](/docs/how-tos/general/providers/).

### Cluster types
Webscale supports two different types of clusters: VM and Kubernetes.

- [VM Clusters](/docs/how-tos/general/vm-clusters/)
- [Kubernetes Clusters](/docs/how-tos/general/kubernetes-clusters/)

Once created, cluster configurations and their blueprints can always be edited. VM cluster deployments can be managed manually or through [Managed Deployments](/docs/how-tos/advanced/managed-deployments/). Kubernetes clusters deploy Helm charts and are always managed through Managed Deployments.

### Associate the cluster to an application

Once you've added a cluster you can link it to an application for scaling. To access these settings, log in to your Webscale Dashboard and click the 3 vertical dots on the upper right corner of the box for the application you wish to view and click **Edit** from the dropdown. From here, click **Servers**. Then, choose the existing cluster from the dropdown under **Scaling Cluster**.

## Further reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# VM Clusters
URL: https://docs.webscale.com/docs/how-tos/general/vm-clusters/
Description: Create server based Webscale clusters



A Virtual Machine (VM) cluster is a server based cluster that scales horizontally in response to increasing or decreasing traffic. VM Clusters are composed of cluster servers which are created based on one or more user provided server blueprints.

## Prerequisites

In order to create a VM cluster, you must first add your Provider via the **Providers** tab. For more information, check out [Working with Providers](/docs/how-tos/general/providers/). Creating a provider will automatically create the VM service necessary to create VM clusters.

## Create a VM cluster

To create a cluster, click the **Clusters** tab and then click **Add cluster**. Next you will define the properties of the cluster.

{{% alert title="Note:" %}}
If you have additional cluster service types enabled in your provider, you may be prompted to select a cluster type. For VM clusters, select "virtual-machine".
{{% /alert %}}

{{< figure src="/images/add-cluster.png" width="75%" alt="Add VM Cluster Dialogue" >}}

| Property            | Description                                                                                   |
| ------------------- | --------------------------------------------------------------------------------------------- |
| Name | Name of the Webscale cluster. |
| Min size | Minimum number of servers in the cluster at any given time. |
| Max size | Maximum number of servers allowed in the cluster. |
| Min increment | When scaling is necessary, increment server count by this amount at a time. |
| Manual size | A specified number of servers for the cluster (overrides minimum and maximum). |
| Healing delay | The amount of time a server can be unreachable before it is replaced. |
| Failed server disposition | The protocol to initiate when a server has failed. |
| Verify timeout | The amount of time to attempt to verify a server before initiating failure protocol. |
| Servers update webhook | Webhook address to notify when a server in the cluster has changed. |
| Measurement type | The method of gathering utilization metrics from each server in the cluster. |
| Allocate public address | Whether or not to allocate a public address for each server in the cluster. |
| Manage Deployments | See [Managed Deployments](/docs/how-tos/advanced/managed-deployments/). |
| Blueprint | Server blueprints define the properties of the servers in the cluster. Input options vary based on the provider service selected. You must specify at least one blueprint to create a cluster. See [Defining your server blueprints](#defining-your-server-blueprints). |
| Scale in/out when | Predefined conditions that determine when the cluster will scale. |

Once you have specified the details of your cluster configuration, click **Save** to create the cluster. If you have specified a minimum size of greater than 0, your cluster will immediately begin scaling out. This can be monitored via the **Task monitor**.

## Defining your server blueprints

Click "Add a blueprint" to add a server blueprint to your cluster. Multiple blueprints may be provided for VM clusters.

After selecting which service you would like to use to provision the server, you will be presented with configuration options specific to that service provider.

{{< figure src="/images/vm-bp.png" width="75%" alt="VM Blueprint Editor" >}}

### Metadata

{{< figure src="/images/cluster-blueprint-metadata.png" width="75%" alt="Metadata" >}}

For select providers, you have the option to specify key/value pairs that are made available on servers created using that blueprint.
The key/value pairs provided will be mounted on every cluster server at `/var/lib/webscale/metadata.json`.

The format for each entry will be:
```
{"key" : "my-key", "value" : "my-value"}
```

Note: This feature cannot be used in conjunction with bootstrapping.

### Files

{{< figure src="/images/cluster-blueprint-files.png" width="75%" alt="Files" >}}

For select providers, you have the option to specify files that are made available on servers created using that blueprint. Upload a file via [Webscale Files](/docs/how-tos/general/files/) as type "Microsite" and it will become available for selection in the cluster blueprint editor. In the cluster editor, select a previously uploaded file, choose the path within that compressed file, and then specify the location on the cluster server where you would like to mount the file.

When the cluster scales, the specified file will be mounted at the specified location on every server created from that blueprint.

Files must be uploaded to your Webscale account prior to blueprint creation via the **Files** tab.

Note: This feature cannot be used in conjunction with bootstrapping.

## Further reading
- [Kubernetes Clusters](/docs/how-tos/general/kubernetes-clusters/)
- [Managed Deployments](/docs/how-tos/advanced/managed-deployments/)
---
# Kubernetes Clusters
URL: https://docs.webscale.com/docs/how-tos/general/kubernetes-clusters/
Description: Deploy Helm charts to an Amazon EKS cluster



A Kubernetes cluster is a Webscale cluster that deploys a Helm chart to an Amazon Elastic Kubernetes Service (EKS) cluster. Every deployment installs your chart as a Helm release in its own namespace. Webscale verifies that its proxies can reach the release, then routes traffic to it. Because the previous release keeps running until the destroy delay expires, a rollback is immediate. Your chart controls replica counts and pod autoscaling.

## Prerequisites

- **EKS cluster:** The [EKS stack](/hosting-platforms/hosting-v4/stacks/eks/) creates and manages one in your AWS account, including the security group rule for the Webscale proxies. An EKS cluster you built yourself must let the proxies reach the NodePort range `30000-32767`. Private nodes must be in the data plane's VPC or in a network joined to it, and the security group opens the range. The provider's IAM user must have cluster admin access through an EKS access entry. The EKS stack grants one to the `Webscale` IAM user and to each ARN in [`kubernetes_admins`](/hosting-platforms/hosting-v4/stacks/eks/#cluster-access). The Webscale Control Plane must reach the EKS cluster's public API endpoint, which the EKS stack configures for you.
- **AWS provider:** Check **Use for Kubernetes** on the provider and enter the EKS cluster name in **Cluster Name**. The provider's region must be the region of the EKS cluster. Saving the provider creates the Kubernetes service that Kubernetes clusters deploy through. See [Working with Providers](/docs/how-tos/general/providers/).
- **Managed deployments:** Kubernetes clusters are always managed. See [Managed Deployments](/docs/how-tos/advanced/managed-deployments/).
- **Chart file:** Package the chart directory as a .zip, .tar, or .tar.gz with `Chart.yaml` and the `templates` directory at the root of the archive. Upload it on the **Files** page with the Helm chart file type (`helm-chart` in the API). See [Working with Files](/docs/how-tos/general/files/).

## Chart requirements

Webscale installs the chart with Helm and reads one Service from it. The chart has to meet these rules.

- **NodePort Service:** One Service receives the traffic. Name it in the blueprint. It needs a selector and exactly one port. Do not set `nodePort`. Two releases run side by side, and a fixed port collides. The proxies connect to the nodes on that node port directly, without a load balancer. Both `externalTrafficPolicy` values work, but leave it at `Cluster`, the default. Webscale refreshes the node list once a minute, and between refreshes a node that lost its pod still forwards traffic under `Cluster` but refuses it under `Local`.
- **Namespace:** Do not set one in the chart. Each deployment installs into a new namespace whose name is the deployment's ID. The namespace starts empty, and Webscale deletes it with the deployment. Pull secrets, quotas, and network policies come from the chart. Webscale passes the values `webscale_cluster_id`, `webscale_deployment_id`, and `webscale_namespace` to the chart, and they override values of the same name.
- **Cluster-scoped resources:** Two releases run side by side during a deployment and the destroy delay. The chart cannot carry CRDs, ClusterRoles, or webhooks that two copies would share. Plan node capacity for two copies.
- **PodDisruptionBudget:** [Karpenter](https://karpenter.sh/) on the EKS stack evicts pods when it removes a node. A budget on the serving pods keeps enough of them running.
- **Secrets:** Declare an ExternalSecret against the `aws-secretsmanager` store the EKS stack installs. See [Secrets](/hosting-platforms/hosting-v4/stacks/eks/#secrets) on the EKS stack page.

## Create a Kubernetes cluster

To create a Kubernetes cluster, click the **Clusters** tab and then click **Add cluster**. Choose the Kubernetes service of your provider in the **Service** field. The editor then shows these properties.

| Property | Description |
| :--- | :--- |
| Service | The Kubernetes service of the provider. The field locks once the Kubernetes cluster has a blueprint. |
| Name | Name of the Kubernetes cluster. |
| Hostnames, Labels | Optional, the same as for a VM cluster. A change to the hostnames starts a deployment. |
| Min size, Max size, Manual size | A minimum size above 0 deploys the Kubernetes cluster on creation. A maximum size of 0 destroys its deployments, and the API refuses a minimum of 0 while an application routes to the Kubernetes cluster. Remove it from the application first. Raising the maximum above 0 deploys again. Replica counts come from your chart, not from these sizes. A future update will simplify these fields and remove **Scale out when**, which does not apply to a Helm release. |
| Verify timeout | The time in seconds Webscale waits for the release to become ready, and then again for a proxy to reach it. Defaults to 600. |
| Destroy delay, Retained configuration count, Enable maintenance mode during deployments | The managed deployment settings, the same as for a VM cluster. See [Managed Deployments](/docs/how-tos/advanced/managed-deployments/). |
| Blueprint | The Helm blueprint. See [Defining the Helm blueprint](#defining-the-helm-blueprint). |

Once you have specified the properties of your Kubernetes cluster, click **Save**. With a minimum size above 0, the first deployment starts at once. A Kubernetes cluster created with a minimum size of 0 deploys at the next change to its blueprint. You can monitor progress in the **Task monitor** or on the **Clusters** page.

## Defining the Helm blueprint

A Kubernetes cluster has one blueprint, and it describes the Helm release.

| Property | Description |
| :--- | :--- |
| Helm chart reference | The chart archive uploaded as a Webscale file. *Required*. |
| Release name | The Helm release name. Each deployment installs its own copy of the release into its own namespace. *Required*. |
| Service name | The name of the NodePort Service in the release that receives request traffic. *Required*. |
| Helm chart values (YAML) | Values passed to Helm on top of the `values.yaml` in the chart. |

The release does not use the metadata and files of a Helm blueprint. Pass configuration through the chart values.

In the API, the blueprint looks like this:

```
"server_blueprints": [
  {
    "name": "helm",
    "service": "/v2/services/abc123",
    "helm_chart_reference": "/v2/files/xyz789",
    "helm_chart_values": "<base64 encoded YAML>",
    "helm_release_name": "my-release",
    "helm_service_name": "my-service"
  }
]
```

A `helm_chart_reference` names the file, and each install uses the current version of that file. To deploy a new chart, upload it as a new version of the file and make that version current. Then change the blueprint, for example its values, to start a deployment. See [Automated Deployments](/docs/how-tos/advanced/managed-deployments/#automated-deployments) for an example.

## Deployment steps

A deployment starts when you save a change to the blueprint, such as new values or a different chart file, or to the Kubernetes cluster's hostnames. It also starts when you raise the maximum size from 0. Changes to the destroy delay or the retained configuration count do not deploy.

1. **Install:** Webscale runs `helm upgrade --install --wait --create-namespace` in the namespace of the deployment. The output of Helm appears in the task log as it arrives.
2. **Verify:** Webscale checks that the named Service is a NodePort Service with one port and a selector. It registers the nodes that serve the Service and tests the connection from every proxy of the applications that use the Kubernetes cluster. A Kubernetes cluster without an application skips the test.
3. **Activate:** Traffic moves to the new release. Webscale keeps the previous deployment for the destroy delay, and **Rollback** reactivates it without a Helm run.
4. **Destroy:** After the destroy delay, or on a failure or a cancel, Webscale uninstalls the release and deletes its namespace. A failed deployment never touches the release that serves traffic.

Every minute, Webscale re-reads the nodes that serve the Service and sends the proxies the new addresses when they change.

## Troubleshooting

The task log names the cause of a failed deployment. These are the common messages.

| Message | Cause and fix |
| :--- | :--- |
| `Deployment my-cluster-abc12 failed. The Helm chart could not be loaded.` | The chart archive could not be read, or its file version is gone. Package the chart with `Chart.yaml` and the `templates` directory at the root of the archive, upload it again, and make that version current. |
| `Waiting for my-eks-cluster to become available. Attempt 3 of 10.` | Webscale cannot reach the EKS cluster's API. After 10 attempts the deployment fails with `my-eks-cluster did not become available after 10 attempts.` Check **Cluster Name** on the provider, and that the provider's region is the EKS cluster's region. For an EKS cluster you built yourself, check that the Webscale Control Plane can reach its public API endpoint. |
| `Deployment my-cluster-abc12 failed because Helm could not install release my-release.` | Helm failed before the timeout, usually because it rejected the chart. Its output is in the log above the message. |
| `Deployment my-cluster-abc12 failed because release my-release did not become ready within 600 seconds.` | The pods did not become ready in time. The lines above the message name each container that did not start and its reason. |
| `A helm_service_name is required to find the Service that receives traffic.` | The blueprint names no Service. Set **Service name** in the editor, or `helm_service_name` in the API. |
| `Service my-service not found in namespace a1b2c3d4e5f6.` | The chart created no Service by that name in the deployment's namespace. The message repeats until the verify timeout. Set the blueprint's Service name to the Service the chart creates. |
| `Service my-service is of type ClusterIP. The proxies reach a cluster by address, so it has to be a NodePort Service. Deployment my-cluster-abc12 failed.` | Change the Service type to `NodePort`. |
| `The Service exposes 2 ports. Expose exactly one, so the origin port is unambiguous. Deployment my-cluster-abc12 failed.` | Keep one port on the Service. |
| `The Service needs a selector to find its pods. Deployment my-cluster-abc12 failed.` | Add a selector to the Service. |
| `No application uses this cluster, so there is no proxy to run the reachability test.` | Not an error. Assign the Kubernetes cluster to an application to get the test on the next deployment. |
| `Waiting for a proxy to run the reachability test.` | The applications that use the Kubernetes cluster have no active proxy yet. The message repeats until the verify timeout. |
| `Proxy 203.0.113.10 cannot reach 192.168.1.20:31234. The security group on the nodes has to allow the Webscale proxy addresses on the node port.` | The message repeats until the verify timeout. On the EKS stack, add the network of the proxies to `service_ingress_cidrs`, or `0.0.0.0/0` when the nodes are public. Connect the networks as well when the nodes sit in a VPC the proxies cannot reach. On an EKS cluster you built yourself, route to the proxies and open the NodePort range to their addresses. |
| `Verification timed out after 600 seconds. Deployment my-cluster-abc12 failed.` | The lines above name what Webscale waited for, such as a proxy that could not reach a node or pods that did not become ready. Fix that cause, or raise **Verify timeout** when the pods only need more time. |

## Further reading

- [Creating Clusters](/docs/how-tos/general/clusters/)
- [VM Clusters](/docs/how-tos/general/vm-clusters/)
- [Managed Deployments](/docs/how-tos/advanced/managed-deployments/)
- [EKS stack](/hosting-platforms/hosting-v4/stacks/eks/)
- [Working with Providers](/docs/how-tos/general/providers/)
- [Working with Files](/docs/how-tos/general/files/)
---
# How to Enable Application Uptime Monitoring
URL: https://docs.webscale.com/docs/how-tos/general/monitoring/
Description: Enable application uptime and error rate monitoring in the Webscale Control Panel



Webscale allows you to enable uptime and error rate monitoring for your application. You can either enable passive monitoring or active monitoring.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**. Then, click the **Monitoring** button on the left menu.
{{% /alert %}}

## Monitoring modes

#### None
No monitoring of client error rate or application up/down state is done. Note that all other alerts are independent of this setting.

#### Passive
Error rates for requests to the site are monitored and alerts are created when the ratio of errors to non-errors is over a threshold.

#### Active
Requests are regularly made to the application via Pingdom, and alerts are created when multiple successive requests fail.

## Set monitoring modes
To set the monitoring mode you desire, click in the **Mode** dropdown to the right and choose the desired mode. Confirm your choice by clicking the **Apply** button on the notice that shows, or cancel the change by clicking **Revert**.

#### Notifications

When monitoring is enabled, it will send alerts based on the notification preferences set in the **Alert Notifications** page. More information on notifications can be found on [How to Enable Notifications](/docs/how-tos/general/notifications/).

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [How to Enable Notifications](/docs/how-tos/general/notifications/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Testing Your Application
URL: https://docs.webscale.com/docs/how-tos/general/app-testing/
Description: Test your application through the Webscale Control Panel



Through the optional application testing feature, you can perform load tests for your application. The test results can help you find possible problems like performance bottlenecks. You can use this feature to test your application after making changes to it.

The application testing feature provides the means to run load tests. Webscale or your developer will create customized tests to meet your needs. The test design specifies the application test paths, what to test, and test methodology.

For example, you could request load tests to measure cache, full-functionality, and checkout performance. Before holding a big sale, you might run a cache test designed to understand if your CDN and site cache will serve cached content instead of sending requests to origin.

While load tests can target different system components, they all measure performance using the same categories, such as request and response counts and average throughput. For more information about the types of information that load tests capture, see [Test results](#test-results).

You can view test results reports through the test results page. You can access this page though the **Application testing** and **Reports** pages. For more information on viewing application test results through the **Reports** page, see [Viewing Reports](/docs/how-tos/general/reports/).

## Topics

- [Getting started](#getting-started)
- [Access the Application testing page](#access-the-application-testing-page)
- [Upload tests](#upload-tests)
- [Work with uploaded tests](#work-with-uploaded-tests)
    - [Download](#download-test)
    - [Edit](#edit-test)
    - [Delete](#delete-test)
- [Run tests](#run-tests)
- [Test results](#test-results)

## Getting started

After you have purchased this feature, you or Webscale must complete the following tasks before you can run tests.

1. Your developer or Webscale creates tests, according to your specifications.
2. On the **Webscale Control Panel** page, access the **Application testing** page.
3. You or Webscale uploads the files for the tests.</br>

    When you select the uploaded files, an icon panel that enables you to download, edit details, delete, and run tests displays for each test when you select it.

## Access the Application testing page

After Webscale has enabled the application testing feature, the **Application testing** sidebar menu option displays.

The **Application testing** page enables you to upload and run load tests. The tests are listed in the left panel.

When you select a test, details for the test display in the **Test details** section of the right panel. You can access the test results through the **Test result** section of the right pane.

 {{< figure src="/images/application-testing/app_test_panels.png" align="left" width="80%" alt="Application testing page" >}}

#### To access the Application testing page

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Application testing**.

   {{< figure src="/images/application-testing/select_application_testing.png" align="left" width="100%" alt="Select Application testing" >}}

   The **Application testing** page displays.

## Upload tests

Test files must be in the .zip, .tar, or .tar.gz file format. If Webscale is creating the tests, it might also upload them.

#### To upload a test

1. In the left panel of the **Application testing** page, click the **Create test** link.

   {{< figure src="/images/application-testing/app_test_create_test_link.png" align="left" width="100%" alt="Click Create test link" >}}

2. In the **Create test** dialog box, enter a test name and, optionally, a description.
3. Click **Choose File**.


4. Select a file on your computer and click **Open**, or drag-and-drop it to the **File** box.
5. Click **Save**.</br>

    {{< figure src="/images/application-testing/app_test_create_test_dialog.png" align="left" width="79%" alt="Click Choose File" >}}

    The new test entry displays in the left panel of the **Application testing** page.</br>

    If another test was selected when you clicked the **Create test** link, it remains selected and the test information for it displays in the right panel.

   {{< figure src="/images/application-testing/app_test_new_test_selected.png" align="left" width="100%" alt="Click Choose File" >}}

## Work with uploaded tests

For uploaded test files, you can perform the following operations.

- [Downloading](#download-test)
- [Editing](#edit-test)
- [Deleting](#delete-test)
- [Running](#run-tests)

For information about running tests, see [Run tests](#run-tests).

### Download test

#### To download a file

Select the file and click the **Download test** icon <i class="fas fa-download" aria-hidden="true"></i> for it.

### Edit test

When you edit tests, you can modify the test description and replace the test by uploading a different file. You cannot modify the test name.

#### To edit a test

1. Select the test and click the **Edit test** icon <i class="fas fa-edit" aria-hidden="true"></i> for it.

    {{< figure src="/images/application-testing/app_test_click_edit.png" align="left" width="100%" alt="Click Edit test icon" >}}

2. In the **Edit test** dialog box, to modify the test description, enter a new description or update an existing one.
3. To replace the test, click **Choose File** and upload a new file.

    {{< figure src="/images/application-testing/app_test_edit_dialog.png" align="left" width="80%" alt="Click Choose File" >}}

4. Click **Save** when you are finished editing the test.

### Delete test

#### To delete a test

1. Select the test and click the **Delete test** icon <i class="fas fa-trash-alt" aria-hidden="true"></i> for it.
2. Click **Ok**.<br>
    The test will no longer display in the list.

## Run tests

Each time that you run a test, you can configure how it will run by specifying the test parameters. The configuration consists of the following two required settings.

- **Duration**: Length of test (in seconds)
- **Virtual Users**: Number of virtual users that the test uses to simulate site visitors. The number of users represents your normal customer load plus a buffer.

#### To run a test

1. In the left panel of the **Application testing** page, select the test to run.
2. Click the **Run test** icon <i class="fa fa-caret-right fa-lg" aria-hidden="true"></i>  for it.

    {{< figure src="/images/application-testing/app_test_click_run_test_icon.png" align="left" width="100%" alt="Click Run test icon" >}}

3. In the **Run test** dialog box:</br>
    a. Enter how long the test will run in the **Duration** field.</br>
    b. Enter the number of simulated users in the **Virtual users** field.

    {{% alert title="Note:" %}}
 To use the previous configuration, enter the same parameters.
{{% /alert %}}

4. Click **Run**.

    {{< figure src="/images/application-testing/app_test_run_test_dialog.png" align="left" width="100%" alt="Run test dialog box" >}}

    The **Run test** dialog box closes. The state icon in the left panel and **State** in the **Test details** section of the right panel indicate that the test is running.

    {{< figure src="/images/application-testing/app_test_run_test_state_change.png" align="left" width="100%" alt="Test state indicate that the test is running" >}}

    When the test has completed, an entry for the results displays in the **Test results** section of the right panel and the state indicates that the test is not running.

    {{< figure src="/images/application-testing/app_test-new_test_results_entry.png" align="left" width="100%" alt="New test results entry" >}}

5. To view the test results, click the **View report** link for the new test results report.

    {{< figure src="/images/application-testing/app_test_click_view_report.png" align="left" width="100%" alt="Click View report link" >}}

    The test results page with the report for the designated test results displays. You can also access this page through the **Reports** page and view all test results and reports through this page.

## Test results

All test reports capture the following information.

- Request count: Number of requests sent during test
- Average throughput: Total number of requests sent during test divided by the duration of the test (in seconds)
- Average TTFB (time-to-first-byte): Average interval between when a request is sent and the first byte of the response is received
- Responses: Types of responses received during test. Responses are grouped by status code and request URL. Additionally, a count for each group is displayed.

This data is captured at each of the following test steps as well as for the entire test.

- Ramp-up
- Each virtual user session

{{% alert title="Note:" %}}
A virtual user session fails if at least 30% of the response codes are in the 400/500 range.
{{% /alert %}}

{{< figure src="/images/application-testing/app_test_report.png" align="left" width="90%" alt="Test results report" >}}

## Further reading
- [Viewing Reports](/docs/how-tos/general/reports/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Configuring Application Shielding
URL: https://docs.webscale.com/docs/how-tos/general/shielding/
Description: Configure application shielding in the Webscale Control Panel



Application shielding protects application servers from unauthorized traffic. Shields are implemented by utilizing cloud provider networking capabilities, eg. firewalls in Google or security groups in AWS. More information about application shielding is available on the [Application Shielding reference page](/docs/reference/app-shield/).

Configuring a shield will update inbound/ingress rules to permit http and https traffic from Webscale control and proxy servers as well as from whitelisted addresses configured for the application. Traffic from other addresses may be dropped once the shield is selected unless explicitly allowed by higher priority rules.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**. Then, click the **Shielding** botton on the left menu.
{{% /alert %}}

## Current shields

Once you have configured an **Application Shield**, it will show here.

### Remove a shield
If you want to remove a shield, click the **Remove** button, then click **OK** on the confirmation that is shown.

{{% alert title="Note:" %}}
This action is permanent, you will have to recreate the shield if you wish to re-add it.
{{% /alert %}}

### Add a new shield

To add a new shield, choose the provider from the **Select a provider** dropdown, then choose the shield type from the **Select a shield** dropdown. Once you've made  your selections, click the **Add Shield** button to add the shield.

<!-- Todo: add explanations for shield typs from dropdown -->

### Add whitelist IPs to the Shields

Click the toggle to enable this setting and add the [IPs you've whitelisted](/docs/how-tos/security/whitelist/) to the application shield, so they won't be blocked by the shield. To disable this setting, click the toggle again.

## Further Reading
- [Introducing Application Shielding](/docs/Reference/app-shield/)
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Advanced How-To Guides
URL: https://docs.webscale.com/docs/how-tos/advanced/
Description: Guides on using advanced features through the Webscale Control Panel


---
# Webscale CLI Reference Guide
URL: https://docs.webscale.com/docs/how-tos/advanced/webscale-cli/
Description: A list of Webscale CLI commands, including example outputs



The `webscale-cli` command is the Swiss army knife of Webscale commands. Use it to fix permissions, restart servers, check the health of the cluster, and many other things.

{{% alert title="Note:" %}}
The command usage is: `sudo webscale-cli <some-command>`
{{% /alert %}}

Some of the most common uses of this command are to check server health, gather information about clusters, or fix permissions on the filesystem. Note that you must use `sudo` with this command, or it fails.

## Cluster Health
One of the most common uses of the **Webscale CLI** is to check the overall health of the cluster. This command shows information such as MySQL queries, recent file changes, and other details about the cluster and the database.

This command is `sudo webscale-cli health`. An example output is:

{{< figure src="/images/webscale-cli/health.png" width="60%" alt="Webscale CLI health output" >}}

To narrow your results, use the following flags:

| Flag | Explanation |
|----|----|
|`sudo webscale-cli health --changes` | Search the local filesystem under `/var/www` without following symbolic links. |
|`sudo webscale-cli health --changes --deep` | Search `/var/www` and `/var/www/shared` following symbolic links. Generally takes much longer to return data. |
|`sudo webscale-cli health --changes </some/path>` | Specify the directory that you would like to see the most recently changed files in. Change `</some/path/>` to the actual path you want to check. |
|`sudo webscale-cli health --db` | Show the top db queries, sorted from longest to shortest living. It's normal for this command to return no data when the database is not heavily loaded. |
|`sudo webscale-cli health --users` | Show any users currently logged in, and what commands they are running.|
|`sudo webscale-cli health --load-avg` | Show the load average for the last 2 minutes.|
|`sudo webscale-cli health --acs` | Show the results from acs-status: e.g., is `lsyncd` currently syncing to the cluster?|

## Information Gathering

The following subcommands of `sudo webcscale-cli` can be used to gather more information:
- `sudo webcscale-cli apps servers` Return the internal IP address of servers for the applications as defined in the config file, `/etc/lagrange-credentials.yml`
- `sudo webcscale-cli clusters`: Your Webscale application clusters. To see the output of the clusters command, you need to expand your terminal window to 173 columns.<br /> {{< figure src="/images/webscale-cli/cluster.png" alt="Webscale CLI clusters output" >}}
This command accepts the following flags:

| Flag | Explanation |
|----|----|
|`--cluster-name` | Return the cluster name for each application.|
|`--cluster-id` | Return the cluster id for each application.|
|`--private-ips` | Return only the private IP addresses.|
|`--public-ips` | Return only the public IPs.|
|`--ips` | Return only the private IP addresses.|

## Restarting

You can use the webscale-cli command to restart your application servers.

The command is: `sudo webscale-cli restart <service>`

Some options for `<service>`:
 - `apache2`
 - `php5-fpm`
 - `php5.6-fpm`
 - `php7.0-fpm`
 - `lsyncd`
 - `sessions`
 - `magento`
 - `fpc`
 - `apache`
 - `php`
 - `sync`

{{% alert title="Note:" %}}
The `apache`, `apache2`, and `php` flags are used to restart the HTTP server and the PHP-FPM servers.<br />
To use this command, you should know which version of PHP and Apache you need to restart.
{{% /alert %}}

## Security

This is the security subset of tools, which only includes log capture at this time.

The command is: `sudo webscale-cli security`
 - `sudo webscale-cli security --log-capture`: SSH to every app server and run `tar /var/log/apache2/`<br /> Example output: {{< figure src="/images/webscale-cli/log-capture.png" width="60%" alt="Webscale CLI log capture output" >}}

## Deploying
There are two `deploy` subcommands. One fixes permissions on the local dataserver, and one fixes issues on application servers that may prevent automatic syncing.

This subcommand of the webscale-cli command recurses through the `/var/www/web_root` and the `/var/www/shared/` directories to make sure that all the files underneath these two directories have the proper ownership and permissions. It is usually run after any deployment to make sure things are as they should be.

The `deploy` subcommand accepts a path if you want to set permissions on a specific subset of files.
If you have files or directories that you need to exclude from this subcommand, list them in the file `/home/www-upload/skip_files` with one file or directory per line. You may also use Unix filesystem regular expressions.
 - `sudo webscale-cli deploy permissions`<br /> Example output: {{< figure src="/images/webscale-cli/permissions.png" width="60%" alt="Webscale CLI deploy permissions output" >}}
 - `sudo webscale-cli deploy app_permissions`<br /> Example output: {{< figure src="/images/webscale-cli/app-permissions.png" width="60%" alt="Webscale CLI deploy app permissions output" >}}

  {{% alert title="Note:" %}}
  The command `sudo webscale-cli deploy app_permissions` does the same thing as `sudo webscale-cli deploy permissions`, but on the application/web servers that exist when you execute the command.
  {{% /alert %}}

  ## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Managed Deployments
URL: https://docs.webscale.com/docs/how-tos/advanced/managed-deployments/
Description: Using managed cluster deployments



Managed deployments allow for new cluster configurations to be deployed systematically and efficiently following the blue-green release model. Deployment configurations are grouped in the UI in reverse chronological order so users can easily see their deployment configuration history as well as the state of their current deployment.

## Enabling Managed Deployments

{{% alert title="Note:" %}}
Managed deployments are an optional feature that must be enabled per account through an entitlement. Contact [Webscale Support](/docs/getting-started/support/) if you do not have access to this feature and would like it.
{{% /alert %}}

When creating a cluster, users have the option to select a **Manage deployments** checkbox which will enable the feature for the cluster being created. All future deployments will be handled automatically when a relevant configuration change is made to the cluster. Configurations for managed clusters will display in a hierarchical view in the UI (See [below](#understanding-cluster-states).)

{{< figure src="/images/add-kubernetes-cluster.png" alt="Manage deployments" >}}

After enabling "Manage deployments" you will have the option to define additional properties for your cluster:

**Destroy delay**: The amount of time to keep resources running after a new cluster has been successfully deployed. The keeping of resources running can save time in the case where a rollback to a previous configuration is necessary. Additional costs will be incurred due to maintaining resources in the Cloud for the duration of the destroy delay. Clusters being kept due to destroy delay will report a state of "keeping".

**Retained configuration count**: The number of previous cluster configurations to store. These configurations can be viewed and redeployed by clicking "Redeploy" in the Cluster Viewer. This count includes configurations in the "retained" or "failed" state, but does not include cluster configurations in the "running" or "keeping" state. When this count is exceeded, cluster configurations will be deleted from oldest to newest until the count is no longer exceeded.

**Enable maintenance mode during deployments**: When checked, any applications with the cluster assigned to them will enter maintenance mode during deployments. In the event of a deployment failure, the application(s) will remain in maintenance mode. A subsequent successful deployment will cause the application(s) to exit maintenance mode. It can also be disabled manually, see [Managing Maintenance Mode](/docs/how-tos/general/maintenance/).

You can only enable or disable managed deployments during cluster creation. In order to migrate from an unmanaged cluster to a managed one, or vice versa, you must create a new cluster.
## How to execute a new deployment

To execute a new deployment, simply change the configuration of your cluster. When you save that configuration, a blue-green deployment will begin.

{{% alert title="Note:" %}}
Changes to destroy delay or retained configuration count do not result in a new deployment but will affect any previously created cluster configurations.
{{% /alert %}}

In a blue-green deployment, first a new cluster will be created with the new configuration. Once those resources have been created and verified, routing for any applications assigned to that managed cluster will automatically change from the old (‘blue’) cluster to the new (‘green’) one.

### Automated Deployments

To automate your deployments in a CI/CD pipeline, add Webscale API requests at the end of your build process. For example, to deploy a new image tag through the Helm chart of your Kubernetes cluster, write the new values file and execute the following `GET` and `PATCH` requests. The example relies on `jq` being available in your build environment.

```
#!/bin/bash

ACCESS_KEY=<my-access-key>
CLUSTER_ID=<managed-cluster-id>
VALUES_FILE=<path-to-the-new-values-yaml>

# Fetch existing cluster blueprint and update helm_chart_values.
VALUES=$(base64 < "$VALUES_FILE" | tr -d '\n')
BLUEPRINT=$(
  {
    curl -s https://api.webscale.com/v2/clusters/$CLUSTER_ID \
      -H "Authorization: Bearer $ACCESS_KEY" |
    jq .server_blueprints |
    jq -c ".[0].helm_chart_values = \"$VALUES\""
  }
)

# Patch the cluster with the updated blueprint.
curl -X PATCH "https://api.webscale.com/v2/clusters/$CLUSTER_ID" \
  -H "Authorization: Bearer $ACCESS_KEY" -H "Content-Type: application/json" \
  --data "{ \"server_blueprints\": $BLUEPRINT }"
```

This will only change the `helm_chart_values` value in the cluster `server_blueprints` while keeping all other cluster configuration values the same. The managed cluster deployment process will trigger on the `PATCH` with the new values. Once the new deployment is verified, the applications that use the cluster route to the new release. To change the chart itself, upload it as a new version of the Webscale file and make that version current before the `PATCH`. A VM cluster works the same way with the blueprint attribute that changed, such as the image.

If there are other updates you require to make during a deployment or you are unsure how to retrieve an access key, refer to the [API documentation](/docs/api/).

### Rollback and Redeploy

The old (‘blue’) cluster resources will be kept running for the duration of the destroy delay, and can easily be rolled back to by clicking “Rollback” in the UI for that cluster configuration. At the end of the destroy delay, the resources will be destroyed.

You can always redeploy an older cluster configuration, just by clicking the “Redeploy” button in the UI. The only difference between this and “Rollback” is that a “Redeploy” will create a new cluster configuration and will require acquiring new resources in the Cloud.

## Understanding cluster states

{{< figure src="/images/managed-cluster.png" alt="Managed cluster viewer">}}

In the above screenshot, the account contains a managed cluster with five configurations in various states:

- myCluster-0g2o1 was recently deployed and resources are still be created or verified.
- myCluster-h389a is currently the active cluster serving traffic. It is in the "running" state.
- myCluster-5571r is reporting a state of "failed". Something went wrong in creating or verifying this configuration.
- myCluster-jrbl8 is in the "keeping" state. It can easily be rolled back to by clicking **Rollback**.
- myCluster-novuw is in the "retaining" state. The configuration can easily be redeployed by clicking **Redeploy**.


| Icon | State       | Description                                                                                   |
| - |---------------| ---------------------------------------------------------------------------------------------- |
|{{< figure src="/images/circle-regular.png" alt="fa-circle-o" width="23%">}}| Creating | Cloud resources are being allocated. |
|{{< figure src="/images/circle-regular.png" alt="fa-circle-o" width="23%">}}| Verifying | A cluster has been created and we are verifying that it responds to requests as expected. |
|{{< figure src="/images/circle-green.png" alt="fa-circle" width="23%">}}| Running | Cluster is currently up and running. |
|{{< figure src="/images/clock-regular.png" alt="fa-circle-o" width="23%">}}| Keeping | Cluster is not the active cluster, but the Cloud resources are still running. This state indicates that the cluster has been scheduled to destroy after the destroy delay expires. |
|{{< figure src="/images/trash-o.png" alt="fa-trash-o" width="23%">}}| Destroying  | Cloud resources are in the process of being destroyed. |
|{{< figure src="/images/circle-grey.png" alt="fa-circle" width="23%">}}| Retaining | Cloud resources have been destroyed, but we are holding onto the configuration in case the user wants to view or redeploy it. |
|{{< figure src="/images/circle-red.png" alt="fa-circle" width="23%">}}| Failed | Creation or verification did not succeed. |

### Deployment Lifecycle
{{< figure src="/images/cluster-state-deployment.png" alt="Cluster state deployment" >}}

When a new deployment is initiated, resources in the Cloud will be created. Once this is complete, verification on the new cluster will begin. When the cluster successfully responds, the cluster will move into the "running" state. Verification will attempt to retry for the duration of the verify timeout specified in the cluster configuration. If, at the end of this period, the cluster has still not responded successfully, all cluster resources will be destroyed and the cluster will either be marked as "failed" or it will reattempt creation.

### Retirement Lifecycle
{{< figure src="/images/cluster-state-retirement.png" alt="Cluster state retirement" >}}

After a new cluster has successfully verified, entered the "running" state, and routing has been switched to it, the previous cluster will be retired. All Cloud resources will be kept running for the duration of the destroy delay specified in the managed cluster's configuration. During this time, the cluster can be quickly reinstated as the active cluster by clicking **Rollback** in the Webscale Portal. Once the destroy delay has expired, cluster resources will be destroyed and the configuration will be marked as "retained".

The number of retained configurations can be specified by the user in the cluster configuration. Note that failed configurations are also included in this count.

## Further reading
- [VM Clusters](/docs/how-tos/general/vm-clusters/)
- [Kubernetes Clusters](/docs/how-tos/general/kubernetes-clusters/)
- [API Documentation](/docs/api/)
---
# Working with Microsites
URL: https://docs.webscale.com/docs/how-tos/advanced/microsite/
Description: Working with microsites using the Webscale Control Panel



A microsite is a standalone website that displays for your application. A microsite package file (also known as a microsite file) contains the content files for one or more microsites. At a minimum, each microsite will consist of a single html file.

Additionally, a microsite can include assets, such as images or CSS files and files for additional pages. The **Files** page enables you to upload and work with microsite package files. After you have uploaded microsite files for your account, they are available for all account applications.

All types of Web Controls can serve microsites. The default maintenance Web Control for your application uses a standard microsite from the default microsite file, which contains one or more standard microsites. Webscale uses this microsite file to display a maintenance mode page and for other purposes.

You can upload additional microsite package files to replace the maintenance Web Control default microsite file or for other usages. While a microsite file can contain files for several microsites, you can only specify a single  microsite file for a request and response Web Control to serve.

{{< figure src="/images/microsites/microsites_filespage_initial_view.jpg" align="left" width="95%" alt="Files page initial view" >}}

## Topics

- [Shared procedures for working with files](#shared-procedures-for-working-with-files)
- [File requirements](#file-requirements)
- [Preview microsites](#preview-microsites)
- [Standard microsites](#standard-microsites)
- [Captcha pages](#captcha-pages)

## Shared procedures for working with files

Webscale features that use uploaded files, such as microsites and CloudEDGE Workers, share the same procedures for uploading and managing files but not for previewing files. [Working with files](/docs/how-tos/general/files/) includes information and procedures for the following shared operations.

- [Upload files](/docs/how-tos/general/files/#upload-files)
- [Work with uploaded files](/docs/how-tos/general/files/#work-with-uploaded-files)
    - [Downloading](/docs/how-tos/general/files/#download-file)
    - [Replacing](/docs/how-tos/general/files/#replace-file)
    - [Editing file details](/docs/how-tos/general/files/#edit-file-details)
    - [Deleting](/docs/how-tos/general/files/#delete-file)

## File requirements

Through the **Files** page, you can upload microsite package files. A microsite file must fulfill the following requirements.

- .zip, .tar, or .tar.gz file format
- Under 50 MB in size
- Links to internal assets must be relative (pages can also contain links to external websites)

## Preview microsites

After you have uploaded a microsite file, you can preview it. For more information on uploading files, see [Upload files](/docs/how-tos/general/files/#upload-files) in [Working with files](/docs/how-tos/general/files/).

##### To preview a microsite

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper-left side of the screen.
2. On the sidebar menu, select **Files**.

    {{< figure src="/images/files/select_files.png" align="left" width="95%" alt="Files sidebar option">}}

3. In the **Files** page, select a file in the **Files** panel.<br>
   The HTML files and any assets for one or more microsites display in the **Content** panel.

   {{< figure src="/images/microsites/microsites_default_file_selected.jpg" align="left" width="100%" alt="Default file selected" >}}

4. In the **Content** panel, click on an HTML file.<br>
   The **Preview** panel displays a preview of the microsite.

   {{< figure src="/images/microsites/microsites_htmlpage_displayed.jpg" align="left" width="100%" alt="Microsite displayed" >}}

{{% alert title ="Note:" %}}
The preview is an approximate rendering that might not appear exactly the same as it will in production, especially if the HTML file includes JavaScript. Webscale does not support standalone JavaScript files for this feature.
{{% /alert %}}

5. To return to the **Files** panel, click **Files** in the navigation path.

{{% alert title="Note:" %}}
You can preview other types of files in the list, such as image files.
{{% /alert %}}

## Standard microsites

The **Files** page contains a system default microsite package file that contains five standard microsite files. Each of these HTML files is a one-page microsite.

The names for the following files correspond to when they display.

- `captcha.html`: Displays for user challenges
- `index.html`: Displays in lieu of all standard microsite files except for `captcha.html`
- `maintenance.html`: Displays when your application is in maintenance mode
- `queued-reject.html`: Displays when Webscale rejects a deferred proxy request because the proxy request queue is full
- `timeout.html`: Displays when a request times out

{{% alert title ="Note:" %}}
For the default microsite file, all html files, except for the one for captcha, share the same microsite.
{{% /alert %}}

### Standard microsite usage

The **Maintenance web controls** page for your application handles the standard microsites. You can access the default maintenance Web Control through this page.

A maintenance Web Control serves the microsite that displays during maintenance mode. The microsite file selected on the page determines the microsites that automatically display for user challenges, proxy request rejections, and time outs.

Initially, the default microsite file is selected on the **Maintenance web controls** page. The default maintenance Web Control also uses this microsite file.

You can replace the default microsite file with a new file that contains versions of the standard microsites that are customized for your business. The HTML files must have the same file names as the standard ones to display.

A new microsite file might have only one HTML file. If it is named `index.html` and located at the root directory of the package file, the single file will display for proxy request rejections and timeouts but not for captchas.

For more information about the maintenance mode microsite, see [Managing Maintenance Mode](/docs/how-tos/general/maintenance/). For more information on captcha, see [Captcha pages](#captcha-pages).

### Replace the default microsite file

To use customized microsites, upload a microsite file with new content files. Then select the new microsite file in the **Maintenance web controls** page.

For more information on uploading microsite files, see [Upload files](/docs/how-tos/general/files/#upload-files). For more information about maintenance Web Controls, see [Managing Maintenance Mode](/docs/how-tos/general/maintenance/).

{{< figure src="/images/microsites/microsite_replace_file.png" align="left" width="100%" alt="Replacement microsite package file" >}}

## Captcha pages

If your application has a request Web Control with the **Challenge user** action, Webscale will display a captcha whenever your application challenges a user.

The request Web Control uses the `captcha.html` file for the microsite package file that is selected on  the **Maintenance web controls** page. If the selected microsite file does not include a `captcha.html` file, the default Webscale captcha displays.

When you replace the default system microsite file for your application, you can include a new `captcha.html` file that is customized to meet your business needs. For example, you could brand a new captcha by including your logo.

{{% alert title ="Note:" %}}
To have captchas function globally (including countries that do not allow the google.com domain), replace `google.com/recaptcha/` with `www.recaptcha.net` in the captcha file.
{{% /alert %}}

For more information on creating a request Web Control with the **Challenge User** action, see [Protecting Your Site with a Captcha](/docs/how-tos/web-controls/captcha-action/).

### Customized captcha file requirements

You must use the `captcha.html` file name for customized captchas. New captchas files must include the following Webscale-specific HTML code. If the code is not included, the captcha will not display.
```
<div id=”protection-mode-captcha”></div>
```
Webscale uses the above code to display the captcha on the page.
```
<div id=”protection-mode-captcha-error”></div>
```
Webscale uses the above code to display an error message if the captcha fails.

### Replace captcha files

To use a new captcha, perform the following procedure.

1. Create a microsite file that includes a new `captcha.html` file that contains the above html code.
2. Through the **Files** page, upload the new microsite file. For more information on uploading files, see [Working with Files](/docs/how-tos/general/files/).
3. In the **Maintenance web controls** page for your application, select the new microsite file from the **Microsite** drop-down menu and click **Apply**. For information on maintenance mode, including selecting a microsite file for for your application, see [Managing Maintenance Mode](/docs/how-tos/general/maintenance/).

## Further reading

- [Working with Files](/docs/how-tos/general/files/)
- [Upload files](/docs/how-tos/general/files/#upload-files)
- [Work with uploaded files](/docs/how-tos/general/files/#work-with-uploaded-files)
- [Managing Maintenance Mode](/docs/how-tos/general/maintenance/)
- [Protecting Your Site with a Captcha](/docs/how-tos/web-controls/captcha-action/)
---
# Configuring Trusted Proxies
URL: https://docs.webscale.com/docs/how-tos/advanced/trusted-proxies/
Description: Configure Trusted Proxies in the Webscale Control Panel



The Trusted Proxies feature enables you to designate proxy IP addresses for providers that you trust. You can add trusted proxies through the Webscale Control Panel. To use this feature, select address sets with provider IP addresses and choose to enable it.

Trusted proxies can add the `X-Forwarded-For` header to HTTP requests that they send to your Webscale applications. When Webscale receives a message from a trusted proxy, it will use the encoded client IP address as the request address.

If it receives the message from a proxy that it does not trust, it will strip the header and use the most recent peer address as the request address.

### What address sets should be trusted?

If the peer address of an incoming request is contained in one of the address sets, then the `X-Forwarded-For` header is decoded so that the request is treated as coming from the rightmost address that is not contained in any of the address sets.

For example, if **Trusted Proxies** is configured such that it allows 4.5.6.0/24 (that IP address is within a trusted address set) and the request originates from 4.5.6.7 with `X-Forwarded-For: 1.2.3.4, 4.5.6.3`, then the request will be treated as though it came from `1.2.3.4`. More details about the `X-Forwarded-For` header can found on the [Mozilla Developer Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For).

### Trusted Proxies Only

If **Trusted Proxies Only** is enabled, then only Pingdom, the control address, and any proxies added here can access the application. Any other traffic from the internet will be dropped. This setting can add an additional layer of security to your application if you want all traffic to only come from a proxy service such as Cloudflare.

### Trusted Proxies Header

This option changes the header used for **Trusted Proxies**. The choices are:

- `X-Forwarded-For` (default): The usual header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or a load balancer.
- `True-Client-IP`: Services such as Cloudflare and Akamai send this header to identify the IP address of the requester.
- `Custom`: Input your own custom HTTP header here.

## Add trusted proxies

You can add more than one trusted proxy at a time.

### To add a trusted proxy

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select **Edit**.

    {{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/access_edit_action_menu.png" alt="Select edit application" >}}

2. On the sidebar menu, select **Trusted proxies**.

    The **Trusted proxies** page displays.

3. Click **Add an address set** and select a provider in the list.

    {{< figure src="/images/trusted_proxies_select_cloudfront.png" alt="Select Cloudfront" >}}

{{% alert title="Note:" %}}
To add more than one trusted proxy, select additional providers in the address set list.
{{% /alert %}}

4. To enable the optional **Trusted proxies only** setting, click the toggle for it.

5. To, optionally, use a header other than the **HTTPS X-Forwarded-For** default, select **True-Client-IP** or **Custom** in the **Trusted proxies header** drop-down list.

    If you have selected **Custom**, enter the name of the header in the custom field.

6. Click **Apply**.

    {{< figure src="/images/trusted_proxies_select_apply.png" alt="Select Apply" >}}

    The provider displays as a trusted proxy.

    {{< figure src="/images/trusted_proxies_cloudfront.png" width="65%" alt="Cloudfront displays as a trusted proxy" >}}

### To delete a trusted trusted_proxies_select_apply

1. Click the **x** for the listed trusted proxy. The provider no longer displays in the list.
2. Click **Apply**.

## Further reading
- [Working with Address Sets](/docs/how-tos/general/address-sets/)
- [HTTP X-Forwarded-For Headers](/docs/Reference/http-headers/#http-x-forwarded-for-headers)
- [Working with Providers](/docs/how-tos/general/providers/)
---
# Logs on Webscale
URL: https://docs.webscale.com/docs/how-tos/advanced/logs/
Description: A guide to how Webscale handles your application and other logs



Log files are plain text files with messages written to them by a server’s operating system and other installed software. These messages help explain the current state of the system and trace any changes made to the system. For instance, error logs contain any error messages the system has encountered, while access logs contain information about when specific files or programs were accessed.

#### The logs maintained by Webscale include:
- Audit logs
- Server access logs
- Web server access and error logs
- Custom logs (Magento, Wordpress, WooCommerce, etc)
- MySQL logs (if applicable)
- Event logs
- [Content Security Policy logs](/docs/how-tos/web-controls/csp-create/#content-security-policy-logs)
- Logs for all services that make up the operating system

In some Webscale environments, your application will send its logs to a data server. Once these logs are sent they are retained on that data server, and this is the central log server for your entire environment.

The logs available in the [Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/) are web access logs (with the exception of Custom Logs - detailed below). Web access logs capture all web requests sent by user browsers and devices to access the application, including different pages viewed in a session, add-to-cart and checkout operations. The Traffic Viewer enables visualization of access logs, and the ability to write search queries to analyze the data made available. Some event logs are also available in your Webscale Control Panel but for retention purposes, the logs accessible on the data server or pushed to CloudWatch are used.

## Custom Logs

Some environments may be setup with the **Webscale Monitoring Agent (WMA)** to capture and publish text based logs such as web server access and error logs, deployment logs, etc. See [Configuring and Viewing Custom Logs](/docs/how-tos/advanced/custom-logs/) for more on how to configure logging through the WMA and then viewing the resulting logs in the Logs Viewer for easy debugging and troubleshooting.

### AWS CloudWatch

In some environments, Webscale may alternatively install the [AWS CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) agent. This agent sends important logs to AWS CloudWatch, a monitoring and log aggregation service provided by AWS.  Not all logs are pushed to CloudWatch, but logs such as the web server error/access logs, security event logs, and audit logs will be available through CloudWatch. If you are running Magento, Webscale can configure the Magento logs to also be sent to CloudWatch. If you are running a different application, you can work with Webscale to determine which logs must be kept for compliance purposes.
## Log Retention

Log retention can be configured by account admins for both online logs (seen Traffic Viewer) and archived logs. Account level settings control retention of account events, while log retention is configurable per-application and by log type.

Changing the log retention settings will effect your account billing.

#### Log retention fields:
- Online days - the number of days to keep logs in traffic viewer
- Online space allowance (GB) - storage limit for logs kept viewable in Traffic Viewer
- Archive days - number of days to keep archived logs
- Archive space allowance (GB) - storage limit for archived logs

### Account Event Logs

Account event log retention can be set by going to **Account settings** > **Event log retention**.

To retrieve archived logs, go to **Account settings** > **Log archives**. There you can restore and download a selected range of logs that have been archived.

### Custom Logs

Custom log retention can be set by going to **Application** > **Edit** > **Log retention**.

To retrieve archived logs, go to **Application** > **Edit** > **Log archives**. There you can restore and download a selected range of logs that have been archived.

## FAQs:

- **How long are my logs retained?**

    Log retention depends on the Webscale plan you are subscribed to, and any specific log retention periods you are contracted for. Typically, Cloudwatch logs and traffic viewer logs are retained for at least 30 days by Webscale. It is possible to request extended log retention for up to 1 year for audit or compliance purposes.  When extended log retention is enabled, the logs may be stored in storage services (such as [S3 or Glacier](https://docs.aws.amazon.com/s3/?id=docs_gateway) on AWS).

- **If I need to see or obtain copies of a specific log file, how would I go about this?**

    Traffic viewer logs are available to download from the Webscale control panel for administrators of the account. If you are not sure where to find the log, the best thing would be to send in a [support request](/docs/getting-started/support/#create-a-new-ticket).

- **What are the paths/locations of the most common logs?**

    The most common system logs are located under `/var/log/` on the servers they apply to. Magento logs are in `/var/www/site/var/logs/`, and other logs created and managed by Webscale are at `/var/log/webscale/`. Any web server logs end up separated by IP Address in `/var/log/webscale/clients/`. The `var` directory should always be a symlink to the NFS shared directory so that web servers can write to the logs.

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [How to Enforce a Content Security Policy](/docs/how-tos/web-controls/csp-create/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Configuring and Flushing the Site Cache
URL: https://docs.webscale.com/docs/how-tos/advanced/site-cache/
Description: Configure and flush the site cache through the Webscale Control Panel



If you have enabled the Dynamic Site Cache feature, Webscale caches static web pages and resources, such as media assets,  scripts, and API responses, according to rules that define how and when your application servers cache content. If the Site Cache contains the content, Webscale directly delivers cached pages and resources to site users, bypassing your web servers.





You can configure Site Cache rules so Webscale only caches content that can be served to any site user and the resources have a low Time-to-Live (TTL) value. Webscale automatically removes cookies from responses that it sends from the cache.

When Webscale CDN is not enabled, Webscale passes incoming requests to your application servers. If the Site Cache contains the requested content, it returns a response to the browser. If the Site Cache does not contain the content, it forwards the request to your web servers to fulfill. When the web servers send a response, the content is cached on your application servers if the content matches a Site Cache rule. Webscale then forwards it to the site user browser.

When Webscale CDN is enabled, Webscale CDN receives the requests first. If the Webscale CDN cache does not contain the content for a request, Webscale forwards the request to the proxies. For more information on CDN caching, see [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

If you have not created a Site Cache rule, Site Cache is disabled and Webscale will not cache any content.

## Work with Site Cache rules

You can create, edit, delete, and change the execution order of Site Cache rules.

### Site Cache rule settings

Site Cache rules consist of the following settings. The cache key properties define the cache key, which enables finding out if the requested content already exists in the Site Cache.

- **Condition**: Determines if Webscale caches pages and resources. As with Web Controls, you must specify at least one condition for a Site Cache rule to execute.
- **TTL (Time-To-Live)**: Specifies how long a cached page or resource is available for site users. The length of time that Webscale caches a page or resource depends on the TTL value. A high number corresponds to a longer amount of time.
- Cache key properties: Used to construct a cache key for requests matching the rule. The following settings define the cache key.
    - **Browser**: Browser attributes for content optimization that are used to partition the cache, if enabled
    - **Hostname**: Hostname used to partition the cache, if enabled
    - **Query**: Query parameters used to partition the cache, if enabled
    - **Path**: Request path used to partition the cache, which cannot be disabled

## Access the Site cache page

You can create Site Cache rules through the **Site cache** page.

#### To access the Site cache page

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Edit**.

    {{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/access_edit_action_menu.png" align="left" width="45%" alt="Select edit application" >}}

2. On the sidebar menu, click **Site Cache**.

    The **Site cache** page displays.

   {{< figure src="/images/site_cache/site_cache_page_displays.png" alt="Site Cache page" >}}

## Create Site Cache rules

You can create multiple conditions for each rule. You can also create more than one rule. After you save the first rule, you can enable the Site Cache feature.

#### To create a Site Cache rule

1. In the **Site cache** page, click **Add a rule**.

   {{< figure src="/images/site_cache/select_site_cache.png" alt="Click Add a rule" >}}

2. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.

   {{< figure src="/images/site_cache/site_cache_click_add_condition.png" alt="Click Add a condition" >}}

3. In the condition drop-down menu of the **Create condition** dialog box, select a condition.
4. Specify relevant condition settings.
5. Click **Add**, then **Done**.
6. To add more conditions, follow the above procedure for adding a condition.
7. Make sure that all cache key properties are enabled.

   {{< figure src="/images/site_cache/enable_cache_properties.png" alt="Enable cache key properties" >}}

8. Provide a valid cookie name if the property is enabled.

   {{< figure src="/images/site_cache/valid_cookie_name.png" alt="Valid cookie name" >}}

9. The tagging properties allow tagging site cache entries with a tag that can be used to invalidate the cache. If enabled, ensure that a valid header name is provided.

   {{< figure src="/images/site_cache/valid_header_name.png" alt="Valid header name" >}}

10. Optionally, modify the TTL setting:</br>
     Drag the slider to choose from a preset TTL value.</br>
     -or-</br>
     Click the **Custom Time** toggle, then enter the desired TTL (in seconds).

11. In the **Cache site** page, click **Save**.

    {{< figure src="/images/site_cache/site_cache_save_rule.png" alt="Save Site Cache rule" >}}

12. If you have not already enabled Site Cache, click the **Enable site cache** toggle to enable it.
13. Click **Apply**.

    {{< figure src="/images/site_cache/site_cache_enable.png" alt="Apply Site Cache rule" >}}

## Flush the Site Cache

Webscale proxies will cache web content that is served from the backend application servers based on rules defined in the [Site Cache rule settings](#site-cache-rule-settings). File types that are cached can include images, javascript files, CSS files, HTML files and API responses. The images, javascript, and CSS files can also be optionally optimized by [Pagespeed](/docs/how-tos/web-controls/pagespeed/).

There may be times you will want to flush the contents of the site and Pagespeed caches, for instance if a major update was made to the application or site. You can flush the entire cache or specific items in the cache from both the Webscale control panel or the API.

#### Invalidate Site Cache items

{{% alert title="Note:" %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Invalidate Cache...**
{{% /alert %}}

{{< figure src="/images/site-cache-invalidate.png" width="75%" alt="Invalidate Site Cache" >}}

From here, you can invalidate specific items in the Site Cache, or all items in the Site Cache. Specify the items to be invalidated using the URLs of the items or the tags with which the items are cached. Use a wildcard (`*`) to invalidate all items at a specific path. If no path is specified then the entire Site Cache is invalidated. Provide the header names in the tags field with which the entries are cached and need to be invalidated. If the tags are specified along with URLs then an intersection of both will be invalidated. Click **Invalidate** to proceed, or **Cancel** if you no longer need to invalidate the cached items.

#### Using the Webscale API

You can use the Webscale API to purge specific items from the cache rather than the entire cache. On the [API page](/docs/api/), enter your API key in the **Enter your api_key** field. Under **Webscale APIs** locate **tasks** and click on **List Operations**. Once here, click **POST** to expand the `POST` type action. Now add the following information in the text area under the **Parameters** section.

```
{
  "type": "invalidate-cache",
  "target": "/v2/applications/<app_id>",
  "parameters":
   {
      "urls": ["*://example.com/example.html","https://example.com.b/*.jpg"],
      "tags": ["tag1", "tag2"]
   }
}
```

Make sure to replace the placeholder `<app_id>` with your actual Application ID, and replace the example URLs with the actual URLs and example tags with the actual tags of the items to purge from the cache. You can also use the wildcard character (`*`) to have the action apply to multiple URLs. This is particularly useful when you want to clear certain parameters from the cache, such as all images, all web pages, and so forth.

{{% alert title="Note:" %}}
The URLs used here must provide the scheme, host and path. For instance, you can use `*://` to cover both the schemes `http,https`, you can provide `*` as host to target all hosts and you can provide an empty path with `/` or `/*` to cover all the paths present under the host. The tags used here must be valid header names.
{{% /alert %}}

If the action is successful, the API will respond with a `200` status code and will list all the URLs that have been purged from the cache.

## Further Reading
- [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/)
- [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [How to Enforce a Content Security Policy](/docs/how-tos/web-controls/csp-create/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Configuring and Viewing Custom Logs
URL: https://docs.webscale.com/docs/how-tos/advanced/custom-logs/
Description: Use WMA to send logs to the Webscale Control Panel



Webscale has developed a log monitoring agent called the **Webscale Monitoring Agent (WMA)** that can be configured to send application or any application related logs (referred to as **Custom Logs**) to the Webscale Traffic Viewer and the Webscale Logs Viewer for viewing, debugging, and troubleshooting.

The WMA logging service can be configured through the [Cluster blueprint editor](/docs/how-tos/general/clusters/) for VM cluster deployments.

The WMA will monitor specified files for write events and will send the contents of those logs to Webscale. These logs can then be filtered and viewed in the Webscale Control Panel via the Traffic Viewer and Logs Viewer.
## Logging Configuration

{{< figure src="/images/cluster-logging-config.png" width="75%" alt="Logging Config" >}}

When creating a Cluster blueprint, if your application is subscribed to Custom Logs, you will see a configuration prompt to select a logging application. This specifies which application your cluster belongs to. Once selected, you will be prompted to configure your log stream.

A log stream is a group of log entries from a specific file path. We recommend naming your log stream something that will help you quickly identify what logs you are looking at. Then specify a file path to monitor for these logs. This must be an absolute path and cannot be a directory, but you may use a single `*` wildcard to monitor multiple log files in a single directory.

For example: `/var/log/nginx/*.log` as a file path will tell the WMA to monitor for any files with a `.log` extension in the `/var/log/nginx/`directory.

{{% alert title="Note:" %}}
Custom Logs are an add-on feature that may not be enabled for your account or application. Please contact [Webscale Support](/docs/getting-started/support/#create-a-new-ticket) to request access to this feature.
{{% /alert %}}

### Multiline Logs

By default, the WMA will divide your logs into individual log records line by line.
However, a multiline start regex can be specified if your log file contains multiline logs that are divided by a delimiter. This delimiter must appear at the start of the line. To capture these multiline logs, you must provide a regular expression that matches this delimiter.

Often, timestamps are used to divide logs. Here are three common timestamp formats and the regular expression used to match them:

```
Sample timestamp: 1994-11-05T13:15:30Z
Regular Expression: \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z

Sample timestamp: 2023/06/30 19:41:45
Regular Expression: \d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}

Sample timestamp: [2023-06-30T12:07:30.743Z]
Regular Expression: \[\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z\]
```

## Logs Viewer

Custom Logs are viewable in the Webscale Control Panel. These Logs can be crucial for monitoring system performance, troubleshooting issues, and ensuring smooth operations. Custom Logs can be viewed in two locations: Traffic Viewer and Logs Viewer.

The Traffic Viewer is a powerful tool for extracting information from logs, such as Proxy Logs, Pageview Logs, CDN Logs, or Custom Logs, and for viewing aggregate data and trends over time. ([Learn more about the Traffic Viewer](/docs/how-tos/traffic-viewer/)

The Log Viewer is designed for viewing the contents of text based logs (Custom Logs). It simplifies log filtering to allow for swift and efficient debugging and log analysis.

|   |   |
|:---:|---|
|{{< figure src="/images/logs-viewer/action-menu-logs-viewer-option.png" alt="Action Menu Logs Viewer Option" >}} | 1. Login to the Webscale Control Panel, locate the application for the desired Custom Logs, and open the application's action menu. If the account has an entitlement to Custom Logs the Logs Viewer option will be available. This menu is also reachable from the application's dashboard.
|{{< figure src="/images/logs-viewer/traffic-viewer-logs-viewer-button.png" alt="Traffic Viewer Logs Viewer Button" >}} | 2. To reach the Logs Viewer from the Traffic Viewer, change the Log Type to Custom Logs and click the "View in logs viewer" button.
|{{< figure src="/images/logs-viewer/logs-viewer-page-default.png" alt="Logs Viewer Page Default" >}} | 3. By default, the Logs Viewer page does not apply any log filters and hides the filter inputs. The default time range is the most recent 5 minutes. The timestamps on the left of the logs indicate the logs' creation time.
|{{< figure src="/images/logs-viewer/logs-viewer-from-traffic-viewer.png" alt="Logs Viewer Page Traffic Viewer Passes Time and Filter" >}} | 4. If accessing the Logs Viewer via the Traffic Viewer, the time range set in the Traffic Viewer will be used in the Logs Viewer. Any Streams, Addresses, or Message filter parameters set in the Traffic Viewer will also be applied in the Logs Viewer. However, other filters like Filename or Hostname will not be applied.
|{{< figure src="/images/logs-viewer/logs-viewer-range-input.png" alt="Logs Viewer Range Input" >}} | 5. To set a time range, click on the desired start date and input the start time. Then, click on the end date and input the end time. Use the <i class="fa fa-step-forward" aria-hidden="true"></i> "Forward to Now" button to advance the end time to the present, adjusting the start time accordingly to maintain the time range duration.
|{{< figure src="/images/logs-viewer/logs-viewer-show-filters-toggle.png" alt="Logs Viewer Show Filters Toggle" >}} | 6. Activate the "Show Filters" toggle to see the three Log Viewer inputs: the Streams filter (for filtering by various log sources as set in the [Logging Configuration](#logging-configuration)), the Addresses filter (for filtering by the server's IP address that produced the logs), and the Message filter (for filtering by specific words in a log entry, but not fragments of a word). As filters are set, the count of active filters is displayed next to the "Show Filter" toggle.
|{{< figure src="/images/logs-viewer/show-next-button.png" alt="Logs Viewer Show Next Button" >}} | 7. When you reach the end of a log range, you can transition to a new log set by clicking the "Show next 5 min" button. This action sets a new start time immediately after the previous end time and establishes a new end time 5 minutes later. If less than 5 minutes remain until the current time, the button will display "Show until now".
## Further reading
- [Creating Clusters](/docs/how-tos/general/clusters/)
- [VM Clusters](/docs/how-tos/general/vm-clusters/)
- [Managed Deployments](/docs/how-tos/advanced/managed-deployments/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Traffic Viewer](/docs/how-tos/traffic-viewer/)
---
# Configuring Rate Limiting
URL: https://docs.webscale.com/docs/how-tos/advanced/rate-limiting/
Description: Use Web Controls to create rate limits



Rate limiting enables you to control access to a page on your website, using Web Controls. For rate limiting, the configuration of Web Controls creates varying experiences for site visitors depending upon criteria that you specify.

{{% include webcontrol.md %}}

Web Controls define the criteria for rate limiting and actions that occur in response. At a minimum, a Web Control that manages rate limiting includes the rate limiting condition, conditions that set the threshold that trigger rate limiting, and resulting actions.

Rate limiting is one way that you can combine multiple Web Controls that act according to specific request conditions.

The following example is intended to teach you about rate limiting. It demonstrates one of several ways that you can use it.

## Rate limiting example

This example explains one way to rate limit checkout attempts based on user behavior, using address sets and Web Controls. It also includes testing the Web Controls to make sure that they are correctly rate limiting.

**Scenario**: Your application rate limits IP addresses if a site visitor attempts to make five or more requests to the checkout page within one minute.

Review [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/) to understand the normal request rate for your application's checkout page and adjust the Web Controls accordingly. (Through Traffic Viewer, you can view checkout traffic for your application over an extended amount of time. This information enables you to extrapolate trends.)

If you are unsure what rate you might want to choose, you can [contact Support](/docs/getting-started/support/) for assistance.

## Address sets

An address set is a list of IP addresses that Webscale manages and uses in features. There are several types of address sets. For this example, a manual and dynamic address set specify the site visitors to which rating limiting applies.

A dynamic address set consists of a set of IP addresses that Webscale manages and can automatically change over time. A manual address set is a set of static IP addresses that requires you to manually add and delete addresses.

For information on address set types, see [Address set types ](/docs/how-tos/general/address-sets/#address-set-types) in [Working with Address Sets](/docs/how-tos/general/address-sets/).

### Address sets for the example

For this example, add addresses to the manual address set that should not be rate limited, such as your web developer's IP address. The dynamic address set contains the IP addresses of potential bad actors that you want to rate limit.

Before you start creating the request Web Controls for the example, create the following address sets.

-  Dynamic address set named "Rate Limited Addresses"
-  Manual address set named "Rate Limited Address Exceptions."

For information on creating address sets, see [Create address sets](/docs/how-tos/general/address-sets/#create-address-sets).

## Web Controls

When conditions for a request Web Control are met, Webscale applies the specified actions to the request. Webscale runs the same procedure for subsequent Web Controls in the request Web Controls list. If you want to specify a final action, you can only choose one, which runs last. You can re-order the Web Controls in the list to change the progression.

The **Web controls** page enables you to create Web Controls. For more information on creating Web Controls, see [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).

## Create Web Controls for rate limiting

After you create the address sets, you can configure the Web Controls that will use them. For this example, you will create the following two request Web Controls. They will work together in the specified order to rate limit checkout attempts. They must display together in the list of request Web Controls with the Capture Rate Limited Addresses Web Control above the Block Rate Limited Addresses Web Control.

- [Capture Rate Limited Addresses](#create-a-web-control-that-captures-rate-limited-addresses): Automatically adds IP addresses to the Rate Limited Addresses address set for site visitors that exceed the rate limit of checkout attempts.

- [Block Rate Limited Addresses](#create-a-request-web-control-that-blocks-rate-limited-addresses): Rate limits any IP addresses added to the Rate Limited Addresses address set.

    Allows the IP addresses for all other address sets, including the Rate Limited Address Exceptions address set, to access the checkout page even if they meet the rate limit.

After you create the Web Controls, you will [test](#testing) them.

{{% alert title="Note:" %}}
The allowlist for the account is automatically excluded from any configured rate limit conditions.
{{% /alert %}}

## Access request Web Controls

1. Click the <i class="fa fa-ellipsis-v" aria-hidden="true"></i> three vertical dots menu icon on the upper-right corner of the application box and select **Edit**.

   {{< figure src="/images/access_edit_app_box.png" alt="Select Edit from application box" >}}

   -or-

   On your application page, click the **Actions** menu icon and select **Edit**.

   {{< figure src="/images/access_edit_action_menu.png" alt="Select Edit from Action menu" >}}

2. On the sidebar menu, select **Request web controls**. The **Request web controls** page displays.

## Create a Web Control that captures rate limited addresses

When you create the Capture Rate Limited Addresses Web Control that defines rate limited checkout access, you will configure three applicable conditions and one action. If all three conditions are met, the action will execute.

The first condition, URL Matches, specifies the Checkout page as the object of the threshold. The second condition, Rate limit, sets the rate limiting threshold. The third action, IP address not in the set, specifies that rate limiting applies only to IP addresses that are not in the Rate Limited Addresses address set.

The action, Add address to set, adds IP addresses that meet all conditions to the Rate Limited Addresses address set of bad actors. The IP addresses that do not meet the conditions and are not in the Rate Limited Addresses set, including the IP addresses in the Rate Limited Address Exceptions address set, are permitted to exceed the rate limit threshold.

### To create a Web Control that captures rate limited addresses

1. On the **Request web controls** page, click **Add a request web control**.</br>
    The sections for configuring request Web Controls display under the **Edit request web control** heading.

    {{< figure src="/images/web_controls/click_add_a_request_web_control.png" alt="Click Add a request web control" >}}

2. Enter "Capture Rate Limited Addresses" as the Web Control name. Optionally, add a description.

   {{< figure src="/images/rate-limiting/name-rate-limit-web-control.png" alt="Name Capture Rate Limited Addresses Web Control" >}}

3. To add the first condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.</br>
    b. In the condition drop-down menu, select **URL matches**. A section with the **HTTP/HTTPS** drop-down menu for the scheme and **Domain**, **Path**, and **Query** fields displays.</br>
    c. Select a protocol in the **HTTP/HTTPS** drop-down menu. Enter `/checkout*` as the path. Optionally, you can enter a domain and query.</br>

    If you leave the **Domain**, **Path**, and **Query** fields empty, they will default to wildcards. Since the URL matches to everything, the condition does not fulfill its function of helping identifying the object of the threshold.

    {{< figure src="/images/rate-limiting/rate-limit-url-matches-condition.png" alt="URL Matches condition selected and path entered">}}

    d. Click **Add**, then **Done**.
4. To add the second condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition** under the first condition. </br>
    b. In the condition drop-down menu, select **Rate limit**.</br>
    c. Enter `5` as the threshold and `1` as the duration.</br>
    d. In the **Unit** drop-down menu, select **Minutes**.</br>

    {{< figure src="/images/rate-limiting/rate-limit-condition.png" alt="Rate limit condition with threshold">}}

    e. Click **Done**.
5. To add the third condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition** under the second condition. </br>
    b. In the condition drop-down menu, select **IP address not in set**.</br>
    c. In the address set drop-down menu, select **Rate Limited Address Exceptions**.</br>
    d. Click **Done**.

      {{< figure src="/images/rate-limiting/rate-limit-ip-address-not-in-set.png" alt="Select IP address not in set condition">}}

6. To add the action:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add action**.</br>
    b. In the **Type** drop-down menu, select **Add address to set**.</br>
    c. In the address set drop-down menu, select the **Rate Limited Addresses**. </br>
    d. Add an expiration date. You can use the slider. Or, if you would like to set a specific time, the **Custom time** toggle will enable you to to specify the time in seconds. For this example, use one hour as the expiration date.</br>
    e. Click **Done**.

    {{< figure src="/images/rate-limiting/rate-limit-action-add-address.png" alt="Select Rate limited addresses action">}}

6. To the right of the **Edit request web control** heading, click **Done**.
7. Select the **Enabled** checkbox.
8. Click **Apply**.

    {{< figure src="/images/rate-limiting/rate-limit-web-control-apply.png" alt="Create Capture Rate Limited Addresses Web Control">}}

## Create a request Web Control that blocks rate limited addresses

When you create the Web Control that blocks rate limited addresses, define two applicable conditions and one action that defines when Webscale prevents access to the checkout page.

The first condition, Block Rate Limit Addresses, specifies that Webscale will apply action to IP addresses in the Rate Limited Addresses address set. The second condition, URL matches, defines that if the IP address matches the specified path, it is subject to the action. If an IP address meets the two conditions, it will be blocked from the checkout page and Webscale will serve a 403 error code.

### To create a request Web Control that blocks rate limited addresses

1. On the **Web Controls** page, click **Add a request web control**.</br>
    The sections for configuring request Web Controls display under the **Edit request web control** heading.
2. Enter "Block Rate Limit Addresses" as the Web Control name. Optionally, add a description.
3. To add the first condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.</br>
    b. In the condition drop-down menu, select **IP address in set**.</br>
    c. In the address set drop-down menu, select **Rate Limited Addresses**.</br>
    d. Click **Done**.
4. To add the second condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition** under the first condition.</br>
    b. In the condition drop-down menu, select **URL matches**. A section with the **HTTP/HTTPS** drop-down menu for the scheme and **Domain**, **Path**, and **Query** fields displays.</br>
    c. Select a protocol in the **HTTP/HTTPS** drop-down menu. Enter `/checkout*` as the path. Optionally, you can enter a domain and query.</br>
    d. Click <strong>Add</strong>, then <strong>Done</strong>.
5. To add the action:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add action**.</br>
    b. In the **Type** drop-down menu, select **Deny request** under **Final actions**.</br>
    c. Click **Done**.
6. To the right of the **Edit request web control** heading, click **Done**.
7. Select the **Enabled** checkbox.
8. Click **Apply**.

## Testing

{{% alert title="Note" %}}
To successfully test the Block Rate Limit Addresses Web Control, make sure the IP address at your current location is not in the [Rate Limited Address Exceptions](#address-sets) address set. If it is in the list, the rate limiting will not occur.
{{% /alert %}}

### Test rate limit checkout attempts based on the example request Web Controls

For this testing, the request will have `https://example.com/checkout.php` as the domain and `/checkout*` as the path. The following scenario will take place.

You can also review [**Traffic Viewer**](/docs/how-tos/traffic-viewer/filter-traffic-viewer/) to see if the request Web Controls executed as expected. Enter `delivery_status>-1 and status_code>403` into the Traffic Viewer filter.

#### To test the example request Web Controls

1. The request does not match the criteria specified for the Allow Rate Limit Exceptions Web Control. Webscale ignores the final action of `Discontinue` for this Web Control since it does not match.

    The Allow Rate Limit Checkout Access Web Control next processes the request.

2. The request matches the for the Allow Rate Limit Checkout Access Web Control conditions of `5` as the threshold and `1` as the duration. It runs the **Add address to set**, which adds the request IP address to the address set specified for the Web Control.

    The Block Rate Limit Addresses request Web Control processes the request last.

3. Since the request has ht<span>tps://example.com/checkout.php as the domain and `checkout` as the path, it matches the conditions for the Block Rate Limit Addresses Web Control. If the user exceeds five or more attempts to checkout, according to the action for this Web Control, a `403` error will occur and `Forbidden` will display in the web browser.

## Summary

For this scenario, you used address sets and request Web Controls to rate limit the checkout page of a website. This can help reduce load on the checkout page of your application.

Reducing load restricts activity to legitimate and productive activity without permanently blocking traffic that may not be harmful. Using multiple Web Controls in this manner allows for great flexibility and powerful control over your web applications.

## Further reading

- [Web Controls](/docs/how-tos/web-controls/)
- [Working with Address Sets](/docs/how-tos/general/address-sets/)
- [Security How-Tos](/docs/how-tos/security/)
- [How to Enforce a Content Security Policy](/docs/how-tos/web-controls/csp-create/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [CIDR (Classless Inter-Domain Routing) Definition](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)
---
# Working with Monitors
URL: https://docs.webscale.com/docs/how-tos/advanced/monitors/
Description: Create and configure monitors



The monitoring feature enables Webscale to track potential problems or system changes. Monitors generate events when they detect activity that matches or exceeds conditions that you define. They can send email notifications when these events occur.

For example, you can create monitors that notify you about website security violations or when the data transfer for outbound traffic exceeds a threshold.

The monitor type determines the activities that monitors can track.

- **data-transfer-billing**: Monitors data transfer for all account applications
- **logs**: Monitors traffic logs for specified applications
- **data-plane**: Monitors particular data plane attributes for changes
- **signal**: Monitors changes in signals for specified accounts or applications
- **application**: Monitors the configurations and resources of one or more applications in an account

When adding or editing a monitor, shared and type-specific settings become visible after selecting a type.

{{< figure src="/images/monitors/monitor-list.png" alt="Monitors page list" >}}

## Topics

- [Shared monitor settings](#shared-monitor-settings)
- [Data transfer monitor](#data-transfer-monitor)
- [Logs monitor](#logs-monitor)
- [Data plane monitor](#data-plane-monitor)
- [Signal monitor](#signal-monitors)
- [Application monitor](#application-monitors)

## Shared monitor settings

All monitor types share the following settings.

- **Name**: Identifies the monitor
- **Description**: Provides a short description of the monitor's purpose
- **Type**: Specifies monitor type
- **Notify**: Enables sending notifications when events that the monitor tracks occur
- **Log events**: Enables adding events that match monitor conditions to the event logs
- **Manage tickets**: Enables creation of support tickets when the monitor triggers
- **Message**: Enables customizing the notification message for `Notify` or `Manage tickets` actions

The **Type** and **Name** settings are required. The remaining settings are optional.

{{% alert title="Note:" %}}
For the **Notify** setting, you can choose to send notifications to specified email address or to the Splunk On-Call third-party notification system if you have installed this product. (The former name for this system is VictorOps)
{{% /alert %}}

  {{< figure src="/images/monitors/victor-ops-form.png" alt="Specify Splunk On-Call notification" >}}

### Notification messages

{{< figure src="/images/monitors/template-editor.png" alt="Message section" >}}

The **Messages** section enables you to create email notification messages. For some monitors, you can choose to create notifications that indicate potential problems. (A monitor will trigger when thresholds that you have defined are met or exceeded.) Webscale will send recovery messages when the monitor no longer detects potential threat conditions.

When creating messages. You can:

- Type a message in the **Edit** tab that Webscale sends for all circumstances
- Define dynamic messages that change according to the situation

### Dynamic messages

Dynamic messages use variables that reference specific values from your Webscale account. The available variables are visible in the **Context** tab.

### Message section

In the **Message** section:

- **Edit** tab: Displays a sample message that demonstrates how to use the context variables. You can modify or replace this sample message.
- **Context** tab: Displays the available variables for the message
- **Preview** tab: Displays a rendered version of the message
- Message type option menu: Specifies if the message is an alert or recovery notification. Displays when you select the **Context** tab.

When you create dynamic messages, Webscale uses [Liquid](https://shopify.github.io/liquid/) templates to reformat your message into Markdown. Liquid then reformats it from Markdown into HTML for the  email message.

A Liquid template also defines the message format. You can switch to another Liquid template to change the message appearance through Liquid.  Liquid is an open-source template language for web applications. For more information about how to use Liquid, see the [Liquid documentation](https://liquidjs.com/tags/overview.html).

#### Illustrated example

{{< figure src="/images/monitors/monitors_message_summary_tab.png" alt="Monitor dynamic messages illustration" >}}

The above graphic illustrates how you can compose two sentences of a message, using variables from the **Context** tab. The **Preview** tab displays how they will render. The **Alerting logs condition** option menu selection determines that the message is an alert.

In the scenarios for the graphic, the boxes with the colored borders show how a variable can be used and rendered.

{{% alert title="Note:" %}}
Webscale automatically populates the variables in the **Context** tab with corresponding system information. For example, if the host name for a monitor application is "example.com," the application variable will include ``"default_hostname": "example.com"``.
{{% /alert %}}

## Data transfer monitor

The data transfer monitor is present by default and always lists on the **Monitors** page. It tracks data transfer usage for all account applications. It is the only monitor with the **data-transfer-billing** type. While you can edit this monitor, you cannot delete it.

The information that the data transfer monitor collects provides the content for the Data Transfer report.

## Logs monitor

You can view your site's activity in near real-time through Traffic Viewer, which uses Webscale traffic logs information. These logs document the activity for each application.

You can configure monitors for each of the following logs types.

- CDN
- CSP (Content Security Policy)
- Pageview
- Proxy

Through CDN and Proxy logs, you can view the activities that your site’s CDN and application generate. Pageview logs can provide insight into your user experience. CSP reports inform you of violations of your site's security policy.

## Data plane monitor

The data plane monitor lets you know when changes have been made to a particular attribute of the data plane being monitored.

You can use **Monitors** page to perform the following operations.

- [Create data plane monitor](#create-data-plane-monitors)
- [Edit data plane monitors](#edit-data-plane-monitors)
- [Delete data plane monitors](#delete-data-plane-monitors)

### Data planes

Data planes are sets of proxies that service all of your application traffic. They sit between your application and the internet, functioning as reverse proxies. Data planes can perform many functions, such as load balancing, protecting your application, and caching.

Each application is connected to a data plane. Your account can have multiple data planes. Multiple applications can share a single data plane.

### IP addressing

Data planes enable you to manage proxies. Each proxy must have a public IP address. The cloud provider for the data plane, such as AWS, Azure, or Google Cloud Platform, allocates IP addresses for new proxies. When you create or edit a data plane, you can choose the method for assigning IP addresses.

One option is to use a pool of pre-allocated static IP addresses that the provider generates. When Webscale creates proxies for a data plane, it assigns IP addresses from the pool. For deleted proxies, Webscale returns the pre-allocated static IP address to the pool. It can then reassign the static IP address to new proxies.

Another method is for Webscale to allocate a new public IP address when it creates the proxy. The IP address does not belong to a pre-allocated pool. When Webscale deletes a proxy, the address will be released.

### Data plane monitors and static IPs

 Data plane monitors track changes to a specified attribute of a data plane.

 The **static_ips** attribute enables the monitor to record a change to the static IP address set. Depending on the monitor configuration, the monitor can send a notification when a change occurs. For example, a monitor will trigger when static IP addresses are added to a data plane due to an increase in its maximum size.

 You can create monitors and choose the **static_ips** attribute for data planes that do not have the static IP addressing feature enabled. These monitors track changes to this attribute for specified data planes. If you enable this feature for an existing data plane, Webscale will add the data plane's existing IP addresses to its static IP address pool. The monitor will register the change. If you have entered an email address or VictorOps information, Webscale will then send a notification.

### Create data plane monitors

You can create multiple data plane monitors. For instance, you might create a monitor for each of your data planes if you have more than one data plane. Or, you could create multiple monitors for one data plane with different recipients and messages for each monitor.

The **Context** tab of the **Message** section of the **Create monitor** dialog box contains some variables that are specific to the data plane monitor.

{{< figure src="/images/monitors/data-plane-static-ip-monitor-config-example.png" alt="Create data plane monitor" >}}

#### To create a data plane monitor

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. On the sidebar menu, select **Monitors**.
3. In the **Monitors** page, click **Create monitor**.
4. In the **Create monitor** dialog box, select the **object-data-plane** monitor type.
5. Enter a monitor name.
6. Optionally, enter a description for the monitor.
7. To disable logging events that match monitor conditions, toggle the **Log events** switch to off.
8. Specify the data plane to monitor by selecting it from the **Data plane** drop-down menu.
9. Specify the attribute to monitor from the **Attribute** drop-down menu.
10. Optionally, specify the notification recipients in the **Notify** section:<br>

   To send email notifications, make sure that the **mailto** option is selected in the drop-down menu and enter one or more email addresses. Click **Add**.<br>

   -or-<br>

   To use the Splunk On-Call third-party notification system, select **victorops** and enter the api and routing keys. Click **Add**.

11. Define your message in the **Message** section.
12. Click **Save**.

### Edit data plane monitors

You can edit the details for a data plane monitor.

#### To edit a data plane monitor

1. On the **Monitors** page list, select the monitor.
2. Click the edit icon <i class="fas fa-edit" aria-hidden="true"></i> that displays for it.

    {{< figure src="/images/monitors/monitor-list-edit-hover.png" alt="Select edit icon for a data plane monitor" >}}

3. In the **Edit Monitor** dialog box, modify the monitor settings.
    {{< figure src="/images/monitors/edit-static-ip-monitor-form.png" alt="Edit data plane monitor dialog box" >}}

4. Click **Save**.

### Delete data plane monitors

You can delete data plane monitors. If you plan to delete a data plane, you must delete any monitors for it before you can delete it.

#### To delete a data plane monitor

1. On the **Monitors** page list, select the monitor.
2. Click the **Delete file** icon <i class="fas fa-trash-alt" aria-hidden="true"></i> that displays for it.

    {{< figure src="/images/monitors/delete-hover.png" alt="Select delete icon for a data plane monitor" >}}

3. Click **Ok** in the confirmation box.<br>

    {{< figure src="/images/monitors/delete-confirmation-dialog.png" alt="Delete data plane monitor confirmation box" >}}

## Signal monitors

Signal monitors inform you when signals for applications or accounts have been triggered or resolved.

Signals are stateful representations of problems that may occur with configured infrastructure.  Monitors may be configured to observe signals for accounts or applications.  For example, a signal may trigger when an application is unreachable from Australia and then will resolve when that application becomes reachable again.

### Configure signal monitors

Signal monitors may have **Labels** configured.  Labels are how to tell the monitor to observe signals for applications with matching labels.  Application labels may be configured in the [general application settings](/docs/how-tos/general/app-general-settings/#labels).

{{% alert title="Note:" %}}
  When no labels are configured for a signal monitor, the monitor will be observing signals for your account.
{{% /alert %}}

In the advanced signal preferences, an **Inactivity resolution interval** may be configured.  This interval represents an amount of time in seconds that must pass while all relevant matched signals are resolved before resolving the state of a signal monitor.

{{< figure src="/images/monitors/signal-monitor-config-example.png" alt="Signal monitor configuration example" >}}

## Application monitors

Application monitors will trigger when certain configuration or resource-specific criteria are met. At this time, the only resources considered are TLS certificates. The user can configure how many days before expiration the monitor should trigger under the **TLS certificates** section. If the monitor is configured with a **Notify** action, an email will be sent to the configured recipients once a day until the certificate is replaced.

{{% alert title="Note:" %}}
  Application monitors run once a day. They are not automatically run when the monitor's configuration is changed. This means it may take up to a day for a new email recipient to receive their first notification.
{{% /alert %}}

Any number of application monitors may be configured in the account, each targeting different [labeled applications](/docs/how-tos/general/app-general-settings/#labels), with different customized configurations.

{{% alert title="Note:" %}}
  When no labels are configured on an application monitor, all applications in the account will be monitored.
{{% /alert %}}

{{% alert title="Note:" %}}
  By default, an application monitor is automatically created when the first application of an account is created. The monitor will trigger when any certificate in the account will expire in the next 15 days.
{{% /alert %}}

## Further reading

- [Viewing Reports](/docs/how-tos/general/reports/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [CDN Logs Attributes](/docs/how-tos/traffic-viewer/cdn-logs-attributes/)
- [CSP Reports Attributes](/docs/how-tos/traffic-viewer/csp-reports-attributes/)
- [Pageview Logs Attributes](/docs/how-tos/traffic-viewer/pageview-logs-attributes/)
- [Proxy Logs Attributes](/docs/how-tos/traffic-viewer/proxy-logs-attributes/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
---
# How to View Webscale Application Server Information
URL: https://docs.webscale.com/docs/how-tos/advanced/appserverinfo/
Description: How to View Webscale Application Server Information in your Webscale Control Panel



The [Webscale Control Panel](https://control.webscale.com) displays application server information and status. In the control panel you can find out how many servers are currently active, what are those servers' IPs, if any additional servers are being scaled, and more.


## View Application Server Information
|   |   |
|---|---|
|{{< figure src="/images/appserverinfo/webscale-dashboard.jpg" width="75%" alt="Webscale control panel" >}}| From the [Webscale Control Panel's](https://control.webscale.com) main page (called the [Dashboard](/docs/overview/dashboard/), each application section shows the following:<br /><ul><li>Server status and uptime</li><li>Scaling for the last 24 hours</li><li>The number of servers</li></ul>|
|{{< figure src="/images/appserverinfo/app-zoom.jpg" width="75%" alt="Webscale Dashboard" >}}| Click the **Zoom** button to see more details for the specific application.|
|{{< figure src="/images/appserverinfo/application-diagram.jpg" width="75%" alt="Webscale Dashboard" >}}| On the application page, the Application Diagram section shows the currently active servers, as well as any servers currently scaling in or out. A list of the IP address for each server is below the server icon. Hover your mouse over the server icon for additional info.|
|{{< figure src="/images/appserverinfo/performance-charts.jpg" width="75%" alt="Webscale Dashboard" >}}| The Performance section shows the following for the timeframe you have selected:<br /><ul><li>Response time in seconds</li><li>Responses per second</li><li>Server count</li><li>Data transfer in megabytes</li></ul>|
|{{< figure src="/images/appserverinfo/events-log.jpg" width="75%" alt="Webscale Dashboard" >}}| The Events section shows a running log of all events, including scaling in and scaling out events. Click the **Zoom** button for more details and calendar options.|

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Traffic Viewer How-To Guides
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/
Description: Guides on using Traffic Viewer


---
# Using Traffic Viewer
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/traffic-viewer/
Description: Using Traffic Viewer in the Webscale Control Panel




Traffic Viewer presents logs information about your application network traffic. You can drill down to specific logs based on logs type and date range. Additionally, you can filter results based on specific attribute values. The viewer for Traffic Viewer functions as the wrapper for all four types: CDN, CSP reports, Pageview, and Proxy (also known as the Traffic viewer logs type). As such, it displays views for them through a dedicated page for each logs type.

After your logs search has produced results, you can view the logs in two formats: detailed and group. With the detailed format, complete information for the logs displays in the **Records** table. With the group view, only the logs that match the selected group type display. When you move from one format to the other, the logs view in the current format retains the same query criteria as the previous one.

The search filter strongly influences the results. Through the filter history, you can easily duplicate previous queries. The history includes the past 20 filters that you have used during your current session. You can return to a previous search by selecting the corresponding filter and specifying other search criteria.

{{< figure src="/images/traffic-viewer/traffic_viewer_overview.png" width="70%" alt="Traffic Viewer overview" >}}

### To access Traffic Viewer

Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select a logs type option from the **Traffic Viewer** sub-menu.

{{< figure src="/images/traffic-viewer/select_app_logs_type.png" width="80%" alt="Select logs type App menu" >}}

-or-

On your application page, click the **Actions** menu icon and select a logs type option from the **Traffic Viewer** sub-menu.

{{< figure src="/images/traffic-viewer/select_app_logs_action.png" width="35%" alt="Select logs type Action menu" >}}

On the menu that appears, click any one of the options.

## Selecting a log type and metric
In the Traffic Viewer, you can modify the records that are shown in the Records table using the filter bar dropdowns. Select between different log types (Proxy logs, CDN logs, CSP reports, Event logs, Pageview logs, Session logs, or Custom logs) using the **Type** dropdown. The Traffic Viewer graph can display one or more metrics associated with the chosen log type. The available metrics for the selected log type are dynamically update in the **Metric** dropdown.

{{< figure src="/images/traffic-viewer/records_table_filter_bar.png" width="70%" alt="Traffic Viewer Filter Bar" >}}

For graphing multiple metrics, see [Graphing metrics in Traffic Viewer](/docs/how-tos/traffic-viewer/graphing-metrics/).
## Filter builder
You can create a filter that defines the logs query through the **Filter** field. Filtering is a useful way to view only the data that interests you. For example, a filter allows you to match all or part of a log, or match specific parts of logs to other logs. When you transition to another view, the last view’s filter bar stays at the state you left it in. Obtain values from the records and add them to the filter without triggering a new view. Alternatively, take values from the summary table and trigger a new view that adds that value to the filter. For more detailed instructions, see [Filter Building in the Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/).
## Time selection
The time selection is independent of the logs views; in other words, whatever time you have selected persists from view to view. The time picker permits you to select any time range within the last month.

The available time ranges within the last month are shown below.
{{< figure src="/images/traffic-viewer/logs_time_selector.png" width="70%" alt="Traffic Viewer Time Selector" >}}

You can also provide your own start and end times within the last month by selecting the "Custom" option. A customized start time can be provided in the "From" input field and a customized end time can be provided in the "To" input field.
{{< figure src="/images/traffic-viewer/logs_time_custom_selector.png" width="70%" alt="Traffic Viewer Custom Time Selector" >}}

You can compare logs in two time ranges within the last month. This can be achieved by either selecting the "Compare" option in the time picker dropdown or by selecting the "Custom" option in the dropdown followed by checking the "Compare To" box right below the "To" input field for the first time range.
{{< figure src="/images/traffic-viewer/logs_time_compare_selector.png" width="70%" alt="Traffic Viewer Custom Time Selector" >}}
## Graph
The graph plots data points for each log type or metric provided based on the time range selected. The x-axis represents the time period and the y-axis represents the metric.
{{< figure src="/images/traffic-viewer/graph_overview.png" width="70%" alt="Traffic Viewer Graph Overview" >}}
### Metrics
The metrics and their meanings are described below for the corresponding data end points.

Metrics | Explanation |
----------|----------|
| Bytes In Per Second | Bytes received by the Webscale proxy per second, including the HTTP request line and headers.
| Bytes Out Per Second | Bytes sent out by the Webscale proxy per second, including the headers.
| Requests | The total number of records for the corresponding logs type.
| Requests per second | Number of records for the corresponding logs type per second.
| Page Load Time | The time taken to load a page for an application when a pagespeed-based beacon was used.
| Pageviews | The total number of page loads for an application.
| Active Requests | The number of requests that were successfully processed.
| Cluster Server Count | The number of active servers across all clusters.
| Rejected Requests | The number of requests that were dropped and therefore not processed. There are two ways a request could be rejected: <ul><li>The request was waiting to be processed for a time period that crossed the waiting threshold.</li><li>There were already too many requests waiting to be processed and so the new request coming in will not even be queued since the new request would cross the waiting limit and therefore be immediately dropped.</li></ul>
| Static Server Count | The number of active servers that are outside any cluster.
| Suspended Requests | The number of requests that are waiting to be processed. If the new incoming request crosses the limit to the number of active requests that can be processed in one batch, the request will be queued.

For the meanings of the metrics listed below, see [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/).
- Bytes In
- Bytes Out
- Internal Latency (`internal_transport_latency`)
- Queue Latency
- Response Time (`elapsed`)
- Server Latency
- Threats
- Traffic TTFB (`ttfb`)
- DOM Content Loaded
- DOM Interactive
- Pageview Elapsed
- First Contentful Paint
- Largest Contentful Paint
- Pageview TTFB
- Ready State Interactive
### Compare time ranges
When comparing time ranges, the graph is updated accordingly. For the single metric, there are two graph lines with each assigned a color to differentiate their data points for their respective time periods.
{{< figure src="/images/traffic-viewer/graph_compare_time.png" width="70%" alt="Traffic Viewer Graph with compare time" >}}
### Compare metrics
Metrics can be compared by selecting a metric in each of the two select drop-down menus present right next to the "Graph" label below the filter input. When comparing metrics, the graph is updated accordingly. Two graph lines are plotted corresponding to the two metrics with each assigned a color to differentiate their data points. The metrics are placed on the left and right y-axes. The metric on the left y-axis corresponds to the metric selected in the first dropdown (from left to right) and the metric on the right y-axis corresponds to the metric selected in the second dropdown.
{{< figure src="/images/traffic-viewer/graph_compare_metrics.png" width="70%" alt="Traffic Viewer Graph while comparing metrics" >}}
### Group graph
In the [group view](#group-view), when the icon ( <i class="fa fa-chart-line"></i> ) is clicked, the first five groups from the table have their data points plotted for the chosen metric and is displayed in the graph as five colored lines. You can also add a sixth group to the graph. The maximum number of groups you can view is six.
{{< figure src="/images/traffic-viewer/group_graph.png" width="70%" alt="Traffic Viewer Group Graph" >}}
### Graph usability
The graph offers a couple of usability features - drag and hover.
#### Drag
You can click and drag the graph either to the left or right.
- Clicking and dragging to the left sets your time range forward.
- Clicking and dragging to the right sets your time range backwards.
Dragging to the left or right always maintains the same time period between start and end times.
#### Hover
You can either hover over a data point in the graph or over the graph legend.
- Hovering over a data point displays a popover showing the values for the corresponding metrics.
- The graph legend contains all the displayed metrics. It tells you what type of metric corresponds to which line on the time graph. Hovering over a legend metric point highlights the corresponding line in the graph.
##### Hovering over a data point in the graph
{{< figure src="/images/traffic-viewer/graph_with_compare_hover.png" width="70%" alt="Traffic Viewer Graph with Compare Hover" >}}
The popover displays the values for the corresponding metrics. The metrics are identified by the color of the graph line they're associated with.
##### Hovering over an item in the graph legend
{{< figure src="/images/traffic-viewer/group_graph_legend_hover.png" width="70%" alt="Traffic Viewer Group Graph Legend Hover" >}}
Hovering over an item in the legend highlights the corresponding graph line.
## Records view
Use the records view to inspect records on a more detailed and individual level. Access all available information about any specific record here.
{{< figure src="/images/traffic-viewer/records_view.png" width="70%" alt="Traffic Viewer records view" >}}
### Toggle visibility
Click the icon ( <i class="fa fa-eye-slash"></i> ) positioned to the right of the **Records** label above the table to display and hide the records.
### Reference tools
Click the **Reference Tools** button to view the list of address sets available in the account the application belongs to. Clicking on any address set will show you its details like its definition and its address entries. You can edit an address set provided you are an account admin and own the address set.
### Download records
Click the download button to download all of the logs that fit your current log request.
### Columns selector
The search results display in columns in the **Records** table. You can change the default columns of associated information by accessing the columns selector. The columns window of the selector contains all of the attributes for the relevant logs type. When you initially access the columns window, the attributes for the default collection of columns are selected. When you select different attributes, the columns for the associated information exclusively display.
#### To access the columns window
In the logs view, click **Columns** in the row of options to the right of the **Records** table heading.
{{< figure src="/images/traffic-viewer/open_columns_window.png" width="70%" alt="Access columns menu" >}}
#### CDN logs columns selector
The below options are selected by default for the CDN logs viewer.
{{< figure src="/images/traffic-viewer/cdn_columns_selector.png" width="70%" alt="CDN Viewer columns selector" >}}
#### CSP reports columns selector
The below options are selected by default for the CSP reports viewer.
{{< figure src="/images/traffic-viewer/csp_reports_column_selector.png" width="70%" alt="CSP Reports Viewer columns selector" >}}
#### Pageview logs columns selector
The below options are selected by default for the Pageview logs viewer.
{{< figure src="/images/traffic-viewer/pageviews_logs_column_selector.png" width="70%" alt="Pageviews Viewer columns selector" >}}
#### Proxy logs columns selector
The below options are selected by default for the Proxy logs viewer.
{{< figure src="/images/traffic-viewer/traffic_viewer_column_selector.png" width="70%" alt="Traffic Viewer columns selector" >}}

By default, records for only the delivery statuses of `0`, `14`, and `16` display. Whenever the **Delivery status**, **Cache Source**, or **Url Map** column is selected, records for all delivery statuses display.
#### More columns selector options
For all four logs types, there is a three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the columns selection window. Click it to access options to display all columns, or only the default ones.
{{< figure src="/images/traffic-viewer/records_column_selector_options.png" width="70%" alt="Columns selector options" >}}
### Group-by selector
Group the logs by a selected logs attribute from the group-by drop-down menu. Select a logs attribute from this menu to trigger a drill-down and create a new group view.
### Table customization
The records table offers several customization options - sorting, resizing and reordering.
#### Sorting
Click a column header to order logs by that logs attribute in ascending order. Then, click again to reverse the sort order.
{{< figure src="/images/traffic-viewer/table_customization_sorting.png" width="70%" alt="Column sorted in ascending order" >}}
#### Resizing
Hover column headers to make the column selection window visible. The window will provide a darker background color and a line at the head to indicate that the column can be resized.

Then, move the cursor towards the line at the end of the column header hover selection. Clicking and dragging the line will expand or shrink individual column widths.
{{< figure src="/images/traffic-viewer/table_customization_resize.png" width="70%" alt="Resize a column header" >}}

#### Reordering
Hover column headers to make the column selection window visible. The screenshot in the [Resizing](#resizing) section above shows what the column selection window looks like. Then click and hold the mouse down to see the cursor change indicating that the column can be reordered. Then drag and drop the column header to reorder the column.
{{< figure src="/images/traffic-viewer/table_customization_reorder.png" width="70%" alt="Resize a column header" >}}

### Cell options
Access cell options by either right-clicking the data cell or clicking the drop-down arrow that appears on cell hover.
{{< figure src="/images/traffic-viewer/cell_options.png" width="25%" alt="Context menu cell options" >}}

There are several options accessible through this drop-down menu depending on the cell. These options are listed below.
#### Add to filter
Add a predicate to the current filter to only show records that have the cell's value for its column.
#### Replace filter
Overwrite the predicate on the current filter to only show records that have the cell's value for its column.
#### Add to blocklist “Blacklist”
[Add an IP address to the blocklist](/docs/how-tos/security/blacklist/#add-an-ip-address-from-the-traffic-viewer) from the records view. This option only shows up if the cell is an address. Clicking on this option adds the address to the address set that is being used as the application's blocklist.

You get a confirmation of adding the address to the blocklist every time this option is clicked. If the address is already in the allowlist, the address once added will also be in the blocklist. Before adding it to the blocklist, you get a confirmation that you want to add the address to the blocklist when it's also in the allowlist even though the allowlist overrides the blacklisted addresses. Once confirmed, the address is added to the blocklist.

If the address is already in the blocklist, you no longer see the menu option **Add to blocklist “Blacklist”**. Instead this option is replaced with the **Remove from blocklist “Blacklist”** option. Clicking this option gives you a confirmation of the removal of the address. Once confirmed, the address is removed from the blocklist.
#### Add to allowlist "Allowlist"
[Add an IP address to the allowlist](/docs/how-tos/security/whitelist/#add-an-ip-address-from-the-traffic-viewer) from the records view. This option only shows up if the cell is an address. Clicking on this option adds the address to the address set that is being used as the application's allowlist.

You get a confirmation of adding the address to the allowlist every time this option is clicked. If the address is already in the blocklist, the address once added will also be in the allowlist. Before adding it to the allowlist, you get a confirmation that you want to add the address to the allowlist when it's also in the blocklist. Once confirmed, the address is added to the allowlist.

If the address was already in the allowlist, you no longer see the menu option **Add to allowlist “Whitelist”**. Instead this option is replaced with the option **Remove from allowlist “Whitelist”**. Clicking this option gives you a confirmation of the removal of the address. Once confirmed, the address is removed from the allowlist.
#### Group by ______
Drill down to a new [Group View](#group-view) with the cell value as the grouping metric.
#### Show details
Show the view containing all details for that record entry. A double-click on a row will also show these details.

Here's an example of an access log record's details:
{{< figure src="/images/traffic-viewer/record_details.png" width="70%" alt="Record details" >}}

You can navigate to the next or previous record entry's details by clicking the "Next" or "Previous" buttons respectively.
#### Copy ______
Copy the cell value to the clipboard.
## Group view
Use the group view to get a broad analysis of logs. It provides an overview of all logs based on your selected group.
{{< figure src="/images/traffic-viewer/groupshowrecords.png" width="70%" alt="Traffic Viewer group, show logs" >}}
### Back "Arrow" button
Click the arrow button to navigate to the previous records view.
### Toggle visibility
Click the icon ( <i class="fa fa-eye-slash"></i> ) positioned to the right of the "Group" label above the table to display and hide the group logs.
### Graph group button
Click the icon ( <i class="fa fa-chart-line"></i> ) to the right of the visibility icon to apply a grouping to the graph. By default, the data points plotted in the grouped graph reflect the first five groups in the table.
### Group drop-down menu
Update the grouping metric without creating a new view by selecting the new field within the grouping drop-down menu.
### Table customization
The group table offers the same [customization options](#table-customization) as those in the records view - sorting, resizing and reordering.
### Show logs
Select the arrow to continue to drill down to a new "Records View" for the logs in that group. This action triggers the transition to a new records view and adds the grouping value to the filter, thus only showing the logs within that grouping item.
### Aggregate selector
The group table allows you to access more grouping analysis through the **+** aggregate selector menu button.
{{< figure src="/images/traffic-viewer/aggregate_column_selector.png" width="70%" alt="Group table columns selector" >}}

The columns that can be added are called aggregable columns. An aggregate column can be added by the following process:
- Select an operator from the "Operator" dropdown.
- Select an attribute from the "Attribute" dropdown.
- Click the "Add" button.
- More aggregate columns can be added by following steps 1-3.
- Once you have all the columns needed to be displayed, click the "Apply" button.

An aggregate column can be removed from the view by the following process:
- Click the icon ( <i class="fa fa-trash-alt"></i> ) next to the aggregate column label.
- More aggregate columns can be removed from the view by clicking their respective trash icons.
- Once you have all the columns needed to be removed from view, click the "Apply" button.
#### Operators
Aggregable columns are the numerical columns for each logs type.
{{< figure src="/images/traffic-viewer/aggregate_column_selector_operators.png" width="70%" alt="Group table column operators selector" >}}

The operators and their respective meanings are described below:

Operator | Explanation |
----------|----------|
| `Count` | The total number of requests served by the proxy for each of the groups.
| `Avg` | The average numerical value is computed from all the values in the aggregable column.
| `Max` | The maximum numerical value is computed from all the values in the aggregable column.
| `Min` | The minimum numerical value is computed from all the values in the aggregable column.
| `Sum` | The total numerical value is computed from all the values in the aggregable column.
#### Attributes
The aggregable attributes for each of the logs type are listed below. The CSP Report logs do not have any numerical columns and therefore have no aggregable columns. So the "+" button is absent in the group view for CSP logs.
##### CDN logs aggregable attributes
These are the aggregable columns available in the group view for the CDN viewer:
{{< figure src="/images/traffic-viewer/aggregate_column_selector_cdn_logs_attributes.png" width="70%" alt="Group table CDN columns selector attributes" >}}
##### Pageview logs aggregable attributes
These are the aggregable columns available in the group view for the pageviews viewer:
{{< figure src="/images/traffic-viewer/aggregate_column_selector_pageviews_attributes.png" width="70%" alt="Group table pageviews columns selector attributes" >}}
##### Proxy logs aggregable attributes
These are the aggregable columns available in the group view for the traffic viewer:
{{< figure src="/images/traffic-viewer/aggregate_column_selector_traffic_viewer_attributes.png" width="70%" alt="Group table proxy logs columns selector attributes" >}}
## Further reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
- [Working with Address Sets](/docs/how-tos/general/address-sets/)
---
# Graphing Metrics
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/graphing-metrics/
Description: An overview of Traffic Viewer graphing capabilities



The **Traffic Viewer graph** provides a visualization of your application traffic. While the **Records table** offers a granular, line-by-line view of individual log records, the graph transforms this data into aggregated metric series. By mapping these metrics over a specified time range, you can quickly identify traffic spikes, service dips, or unusual patterns that warrant further investigation.

## Traffic Viewer overview
{{< figure src="/images/traffic-viewer/tv_g.svg" width="95%" alt="Traffic Viewer interface overview" >}}
To graph a single metric, select your log type and metric preference from the **Type** and **Metric** dropdowns in the **Records table filter bar**. For more advanced analysis—such as overlaying multiple metrics, comparing different log types, or applying unique filters to individual series—click the **Configure icon** in the top-right corner of the graph.

## Graphing multiple metrics

Clicking the **Configure icon** will expand the **Configuration panel** to allow for the selection of multiple metrics (up to 5) across log types. Each row represents a new series that will be displayed in the **Traffic Viewer graph**. In order to graph another metric, simply select it from the _“Select a metric…”_ dropdown.

In the **Traffic Viewer graph**, axes will be combined when series share the same unit. Otherwise, an additional y-axis will be provided.  Hovering over the data will present a popover tooltip that displays the respective data for the nearest data point. To temporarily highlight a specific series, hover over the series label along the x-axis.

Clicking the **Trash icon** will remove the metric from the graph.

{{< figure src="/images/traffic-viewer/configuration_panel.svg" width="50%" alt="Configure panel expanded" >}}

## Applying filters to graphed metrics

When the **Configuration panel** is first expanded, the first entry is labeled “Records table”. This is a dynamic link: the metric and filters for this series are driven by your selections in the **Records Table filter bar**. Updating either of these fields in the **Records table filter bar** will affect the series metric displayed in the graph.

{{< figure src="/images/traffic-viewer/records_table_filter_bar_connection.png" width="80%" alt="Records table metric" >}}

To modify the other metrics graphed, click the **Settings icon** next to the desired metric in the **Configuration panel**. This will open the **Metric definition** panel which allows you to apply a filter that applies only to the selected metric.

{{< figure src="/images/traffic-viewer/animation.png" width="80%" alt="Animation of metric selection" >}}

## Unlinking and linking the records table filter

If you would like to search through log records without affecting the graphed metrics, you can do so by unlinking the records table from the graph. Toggle the **Line graph icon** in the Records table filter bar and the Records table will then become unlinked from the graph. The existing metric and filter will be preserved in the corresponding “Records table” metric, if it is still displayed, and the corresponding metric selector will be updated to show that it is no longer linked to the “Records table”.

If the “Records table” metric has been *unlinked* from the graph (**Line graph icon** appears gray), but you would like to display a graph using the metric and filter from the **Records table filter bar**, you can toggle the **Line graph icon** and the graph will update with “Records table” displayed as a graphed metric.

## Available metrics

| Source | Description | Metrics |
| :---- | :---- | :---- |
| Application | Core metrics representing the health and capacity of the application. | Requests, Cluster server count, Rejected requests, Static server count, Suspended requests |
| CDN | Data transfer and delivery metrics from the Content Delivery Network. | Bytes in, Bytes in rate, Bytes out, Bytes out rate, Content length, Content length rate, Elapsed, Range end, Range start, Requests, Requests rate, TTFB |
| Cluster | Infrastructure-level telemetry monitoring the physical or virtual resources powering your application. | CPU utilization, Disk space, Disk utilization, IO wait percent, Memory utilization, Normalized load |
| CSP | Content Security Policy metrics tracking browser-reported security violations. | Reports, Reports rate |
| Events | Aggregated counts of system-generated log events categorized by severity level. | All events, Info, Severe, Warning |
| Pageviews | Real-user monitoring (RUM) data focusing on browser-side performance and core web vitals. | Pageviews, DOM content loaded, DOM interactive, Elapsed, First contentful paint, Largest contentful paint, Rate, Ready state interactive, TTFB |
| Proxy | Detailed traffic metrics from the data plane layer, including latency breakdowns and security threats. | Bytes in, Bytes in rate, Bytes out, Bytes out rate, Elapsed, Internal latency, Queue latency, Requests, Requests rate, Server latency, Threats, TTFB |
| Sessions | Aggregated user experience data tracking session duration and average load performance. | Elapsed, Page load average, Page load LCP average, Page load TTFB average, Rate |
---
# Building Traffic Viewer Filters
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/filter-traffic-viewer/
Description: Build Traffic Viewer filters in the Webscale Control Panel




You can use the Traffic Viewer **Filter** field to create filters for the logs search query. Along with the time range and logs type option, the filter defines the query.

The filter builder enables you to easily navigate records to find specific logs interactions. There are many ways to build filters; some methods depend on how you are viewing logs (records or groups view). For information on the records and groups views as well as how to use Traffic Viewer, see [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/).

{{% alert title="Note:" %}}
The Traffic viewer logs type option pertains to proxy logs.
{{% /alert %}}

{{< figure src="/images/traffic-viewer/traffic_viewer_filter_field.png" width="85%" alt="Traffic viewer logs filter field" >}}

# Topics

- [Access Traffic Viewer](#access-traffic-viewer)
- [Basic filter functionality](#basic-filter-functionality)
- [Records view filter functionality](#records-view-filter-functionality)
- [Group view filter functionality](#group-view-filter-functionality)
- [Logs and report attributes](#logs-and-report-attributes)
- [Examples](#examples)

## Access Traffic Viewer

You can access Traffic Viewer for each log type through the Webscale Control Panel.

### To access Traffic Viewer

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select a logs type option from the **Traffic Viewer** sub-menu.

   {{< figure src="/images/traffic-viewer/select_app_logs_type.png" width="80%" alt="Select logs type App menu" >}}

   -or-

   On your application page, click the **Actions** menu icon and and select a logs type option from the **Traffic Viewer** sub-menu.

   {{< figure src="/images/traffic-viewer/select_app_logs_action.png" width="35%" alt="Select logs type Action menu" >}}

## Basic filter functionality

For all Traffic Viewer logs type pages, you can access the following basic filter functionality through the **Filter** field.

- **Example query**: An example query displays in the **Filter** field as a model on how to construct your query.
- **Filter log attributes**: You can see the filter log attributes available for the logs type by clicking on the info icon just above the **Filter** field.
- **Filter history**: If you previously created filters, the last twenty filter queries for your current Traffic Viewer session display in the **Filter** field drop-down menu.
- **Apply filter**: You can apply a filter by clicking **Apply** or pressing **Enter**.
- **Filter errors**: If a query is malformed, an error appears below the **Filter** field.
{{< figure src="/images/traffic-viewer/filtererror.png" width="70%" alt="Traffic Viewer filter error message example" >}}

## Records view filter functionality
{{< figure src="/images/traffic-viewer/filteroptions.png" width="70%" alt="Traffic Viewer filter options" >}}
The records view of query results displays all logs of the selected log type that match the specified time range and filter.

All general filter functionality applies to the records view along with a few additional features that relate to individual cells within a table. You can access these features by right-clicking the cell value or clicking the drop-down arrow that appears when you hover on a cell.
- **Add to filter**: Add a cell value to the filter by selecting **Add to filter** from the drop-down menu for the cell. This action appends the filter-formatted cell value and column header to your current filter. The logs view remains the same and does not trigger a new view.
- **Replace filter**: Replace your current filter with the value of a cell by selecting **Replace filter** from the drop-down menu for the cell. This action applies the filter format to the cell value and header, clears the current filter, and replaces it with the reformatted cell value and header. The logs view remains the same and does not trigger a new view.

## Group view filter functionality
{{< figure src="/images/traffic-viewer/groupshowrecords.png" width="70%" alt="Traffic Viewer group, show logs" >}}

After you create a filter and apply it, you can choose a logs attribute from the **Groups by** drop-down menu to further refine your results. Only results that match the logs attribute for the group display.

All general filter functionality also applies to the group view along with one additional feature:
**Show logs**: To see all logs that apply to a group member, click the right arrow for the selection. This creates a new view with that group member value and header appended to your current filter.

## Logs and report attributes

Depending on the logs type, you can use specific logs and report attributes when you create a filter.

### CDN logs Attributes

For information on the logs attributes available for CDN logs filters, see [CDN logs attributes](/docs/how-tos/traffic-viewer/cdn-logs-attributes/).

### CSP reports attributes

For information on the report attributes available for CSP reports filters, see [CSP reports attributes](/docs/how-tos/traffic-viewer/csp-reports-attributes/).

### Pageview logs Attributes

For information on the logs attributes available for Pageview logs filters, see [Pageview logs attributes](/docs/how-tos/traffic-viewer/pageview-logs-attributes/).

### Proxy logs attributes

For information on the logs attributes available for Proxy logs filters, see [Proxy logs attributes](/docs/how-tos/traffic-viewer/proxy-logs-attributes/).

## Examples
To see all search results, use `delivery_status>-1` in your filter. Then, make changes to the query pattern and drill down the results to find specific types of traffic. You can include wildcards for queries with log attributes that return non-numeric values. To do so, use the **~ (tilde)** character in conjunction with wildcards.

For more information on delivery status codes, see *Delivery status codes* on the [Proxy logs attributes](/docs/how-tos/traffic-viewer/proxy-logs-attributes/) page.

- Find all instances of a 500 error: `delivery_status>-1 and status_code>500`.
- To see all results from a specific IP address, use the `request_address` log attribute: `delivery_status>-1 and request_address=192.0.2.0`
- To check a specific URL on your application, use `request_path`: `request_path="/checkout/cart/" and status_code>=500`
- Sort traffic based on useragent and use the **bot** useragent to see if bot traffic is an issue: `delivery_status>-1 and useragent~*bot*`
- Find all **php** requests that are not going to standard index.php location: `delivery_status>-1 and request_path~*.php* and request_path!~*index.php* and status_code>=400`
- Check traffic to the Magento admin page: `delivery_status>-1 and request_path~*magento_admin_path*`
- Check customer post sql requests: `delivery_status>-1 and request_method~*POST*`
- Isolate traffic from a specific country: `delivery_status>-1 and country!~*US*`
- Global subnet-based requests: `delivery_status>-1 and request_address in 192.0.2.0/16`

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# CDN Logs Attributes
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/cdn-logs-attributes/
Description: Detailed information about CDN logs attributes




The **Traffic Viewer** page in the Webscale Control Panel enables you to view CDN logs information for an application within a specified time period. For more information, see [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/).

The following table provides CDN logs attribute information. You can view the name, display name, alias, and a description for each attribute.

## CDN logs attributes

Name | Display Name | Alias | Description
-- | -- | -- | --
arrival | Arrival | arrival | ISO 8601-formatted date for when the request arrived at the CDN service
aws_edge_error_type | AWS edge error | aws_edge_error <br/> aws_edge_error_type | Error that occurred while the CDN service processed the request
aws_edge_result_type | AWS edge result | aws_edge_result <br/> aws_edge_result_type | How the CDN service classified the response
bytes_in | Bytes in | bytes_in | Bytes that the CDN service received, including request line and headers
bytes_out | Bytes out | bytes_out | Bytes that the CDN service sent out, including response headers
completed | Completed | completed | ISO 8601-formatted date when processing the request was completed
content_length | Content length | content_length | Contents of the Content-Length response header
edge_location | AWS edge location | aws_edge_location <br/> edge_location | Three-letter IATA code for an airport near the edge node that received the request
elapsed | Elapsed | elapsed | Interval between when the CDN service received the request and sent the complete request
peer_address | Peer address | peer_address | IP address of the immediate peer connecting to the proxy. If the peer is a trusted proxy, the remote IP address of the user agent that made the request is used.
range_end | Range end | range_end | End value of the Content-Range response header
range_start | Range start | range_start | Start value of the Content-Range response header
referrer | Referrer | referrer | Contents of the Referer request header
request_address | Request address | request_address | Remote IP address of the user agent that made the request
host | Request host | host <br/> request_host | Contents of the Host request header
request_id | Request ID | request_id | Unique ID for each request that the CDN service serves
request_method | Request method | request_method | HTTP request method
request_path | Request path | request_path | Virtual path of the request (latter portion of the request URL separated by backslashes after the main website name)
request_port | Request port | request_port | Port number that received the request
protocol | Request protocol | protocol <br/> request_protocol | HTTP protocol version
request_query | Request query | request_query | URL request query parameters (located in the latter sections of the request URL)
content_type | Response content type | content_type <br/> response_content_type | Contents of the Content-Type response header
response_status_code | Status code | response_status_code <br/> status_code | Response status code that indicates if a specific request has successfully completed
tls_cipher | TLS cipher | tls_cipher | Encryption algorithms for transport layer security
tls_protocol | TLS version | tls_version <br/> tls_protocol | Highest version of the transport layer security protocol that the client supported
time_to_first_byte | TTFB | ttfb <br/> time_to_first_byte | Interval between when the browser sent the request and received the first byte of the response
useragent | User agent | useragent<br/>user_agent | Contents of the User-Agent request header
useragent_device | User agent device | useragent_device<br/>user_agent_device | Device type used to make the request (e.g., smartphone, desktop, etc.)
useragent_name | Browser | browser<br/>useragent_name<br/>user_agent_name | Browser type used to make the request (e.g., Google Chrome, Safari, etc.)
useragent_os | User agent OS | useragent_os<br/>user_agent_os | Operating system type used to make the request (e.g., Android, Mac, etc.)
x_forwarded_for | X-Forwarded-For | x_forwarded_for | Contents of the X-Forwarded-For request header

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# CSP Reports Attributes
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/csp-reports-attributes/
Description: Detailed information about CSP reports attributes




The **Traffic Viewer** page of the Webscale Control Panel enables you to view CSP reports information for an application within a specified time period. For more information, see [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/).

The following table provides CSP reports attribute information. You can view the name, display name, alias, and a description for each attribute.

## CSP reports attributes

Name | Display Name | Alias | Description
-- | -- | -- | --
arrival | Arrival | arrival | ISO 8601-formatted date when the request arrived at the Webscale proxy
blocked_uri | Blocked URI | blocked_uri | URI of the resource that the Content Security policy blocked from loading. If the blocked URI has a different origin than the document URI, the blocked URI is truncated to contain just the scheme, host, and port.
country | Country | country | Two-letter ISO 3166-1 country code for the origin of a request
disposition | Disposition | disposition | "enforce" if the Content-Security-Policy response header was used. "report" if the Content-Security-Policy-Report-Only response header was used.
document_uri | Document URI | document_uri | URI of the document in which the violation occurred
effective_directive | Effective directive | effective_directive | Directive whose enforcement caused the violation
host | Request host | host<br/>request_host | URL of the application that was requested
original_policy | Original policy | original_policy | Original policy as specified by the Content-Security-Policy response header
peer_address | Peer address | peer_address | IP address of the immediate peer that reported the violation
referrer | Referrer | referrer | Referrer of the document in which the violation occurred
request_address | Request address | request_address | Remote IP address of the user agent that made the request
script_sample | Script sample |script_sample | First 40 characters of the inline script, event handler, or style that caused the violation
session_id | Session ID | session_id | ID of the Webscale session that attempted to load the resource
status_code | Status code |response_status_code<br/>status_code | Response status code that indicates the response to a specific request
useragent | User agent | useragent<br/>user_agent | Contents of the User-Agent request header
violated_directive | Violated directive | violated_directive | Name of the violated policy section

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Pageview Logs Attributes
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/pageview-logs-attributes/
Description: Detailed information about Pageview logs attributes




The **Traffic Viewer** page of the Webscale Control Panel enables you to view Pageview logs information for an application within a specified time period. For more information, see [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/).

The following table provides Pageview logs attribute information. You can view the name, display name, alias, and a description for each attribute.

## Pageview logs attributes

Name | Display Name | Alias | Description
-- | -- | -- | --
arrival | Arrival | arrival | ISO 8601-formatted date when the request arrived at the Webscale proxy
completed | Completed | completed | ISO 8601-formatted date when processing the request was completed
country | Country | country | Two-letter ISO 3166-1 country code for the origin of the request
dom_content_loaded | DOM content loaded | dom_content_loaded | Interval between when navigation started and the page loaded the DOM
dom_interactive | DOM interactive | dom_interactive | Interval between when navigation started and the page was ready for user interaction
elapsed | Elapsed | elapsed | Interval between when the proxy received the request and sent out the complete response
first_contentful_paint | First contentful paint | first_contentful_paint | Interval between when navigation started and the first element on the page rendered
labels | Labels | labels | List of user-defined labels used to track traffic with the Add Labels web control action
largest_contentful_paint | Largest contentful paint | largest_contentful_paint | Interval between when navigation started and the largest element on the page rendered
load_id | Load ID | load_id | Unique ID that identified a user-initiated pageload. All resource requests shared the ID to render the page.
peer_address | Peer address | peer_address | IP address of the immediate peer connecting to the proxy. If the peer is a trusted proxy, the remote IP address of the user agent that made the request is used.
ready_state_interactive | Ready state interactive | ready_state_interactive | Time taken for the loading state of the browser to become interactive. It is interactive when the browser document has finished loading and has been parsed but sub-resources such as scripts, images, stylesheets and frames are still loading.
request_address | Request address | request_address | Remote IP address of the user agent that made the request
request_host | Request host | host<br/>request_host | Contents of the Host request header
request_path | Request path | request_path | Virtual path of the request (latter portion of the request URL separated by backslashes after the main website name)
request_port | Request port | request_port | Port number that received the request
request_protocol | Request protocol | protocol<br/>request_protocol | HTTP protocol version
request_query | Request query | request_query | URL request query parameters (located in the latter sections of the request URL)
request_url | Request URL | request_url | String with the host, scheme, path, and query parameters for the request
session_id | Session ID | session_id | Unique number that a server assigned to a specific user for a session
threat | Threat | threat | "y" if the IP address was a potential attacker. "n" otherwise.
time_to_first_byte | TTFB | ttfb<br/>time_to_first_byte | Interval between when the browser sent the request and received the first byte of the response
tls_cipher | TLS cipher | tls_cipher | Encryption algorithms for the transport layer security
tls_version | TLS version | tls_version<br/>tls_protocol | Highest version of the transport layer security protocol that the client supported
useragent | User agent | useragent<br/>user_agent | Contents of the User-Agent request header
useragent_device | User agent device | useragent_device<br/>user_agent_device | Device type used to make the request (e.g., smartphone, desktop, etc.)
useragent_name | Browser | browser<br/>useragent_name<br/>user_agent_name | Browser type used to make the request (e.g., Google Chrome, Safari, etc.)
useragent_os | User agent OS | useragent_os<br/>user_agent_os | Operating system type used to make the request (e.g., Android, Mac, etc.)

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Proxy Logs Attributes
URL: https://docs.webscale.com/docs/how-tos/traffic-viewer/proxy-logs-attributes/
Description: Detailed information about Proxy logs attributes, cache source codes, and delivery status codes




The **Traffic Viewer** page of the Webscale Control Panel enables you to view Proxy logs attribute information for an application within a specified time period. For more information, see [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/).

The following **Proxy logs attributes** table provides Proxy logs attribute information. You can view the name, display name, aliases, and a description for each attribute. Specific codes, presented in the **Cache source codes** and **Delivery status codes** tables, are returned for the cache_source and delivery_status proxy logs attributes.

## Topics

- [Proxy logs attributes](#proxy-logs-attributes)
- [Cache source codes](#cache-source-codes)
- [Delivery status codes](#delivery-status-codes)

## Proxy logs attributes

Name | Display Name | Aliases | Description
-- | -- | -- | --
arrival	| Arrival	| arrival	| ISO 8601-formatted date when the request arrived at the Webscale proxy
bytes_in | Bytes in | bytes_in | Bytes that the Webscale proxy received, including request line and headers
bytes_out	| Bytes out | bytes_out	| Bytes that the Webscale proxy sent to the client, including response headers
cache_control | Cache control | cache_control	| Contents of the Cache-Control response header
cache_source | Cache source | cache_source | [Two-letter codes](#cache-source-codes) that indicate the action the source took while responding to the request
completed	| Completed	| completed	| ISO 8601-formatted date for when processing the request was completed
country | Country	| country	| Two-letter ISO 3166-1 country code for the origin of the request
delivery_status	| Delivery status	| delivery_status	| [Numeric codes](#delivery-status-codes) that indicate the delivery status of the request. "0" for traffic proxied through to the application. When not "0," the Webscale proxy handled the request directly.
elapsed	| Elapsed	| elapsed	| Interval between when the proxy received the request and sent the complete response
internal_transport_latency | Internal latency | internal_latency<br/>internal_transport_latency	| Internal proxy delay while processing the request
labels | Labels	| labels | List of user-defined labels used to track traffic with the Add Labels web control action
load_id	| Load ID	| load_id	| Unique ID that identified a user-initiated pageload. All resource requests shared the ID to render the page.
location | Location	| location | Contents of the Location response header
peer_address | Peer address | peer_address | IP address of the immediate peer connecting to the proxy. If the peer is a trusted proxy, the remote IP address of the user agent that made the request is used.
proxy_address |	Proxy address |	proxy_address | IP address of the proxy that handled the request
queue_latency | Queue latency |	queue_latency | Amount of time that the request spent queued on the proxy, possibly due to a slow backend
range |	Range | range |	Contents of the Range request header
referrer | Referrer | referrer | Contents of the Referer request header
request_address | Request address	| request_address	| Remote IP address of the user agent that made the request
request_asn | Request ASN | request_asn | Autonomous System Number (ASN) of `request_address`
request_host | Request host | host<br/>request_host | Contents of the Host request header
request_id | Request ID | request_id | Unique ID for each request that the proxy served
request_method | Request method | request_method | HTTP request method
request_path | Request path | request_path | Virtual path of the request (latter portion of the request URL separated by backslashes after the main website name)
request_port | Request port | request_port | Port number that received the request
request_protocol | Request protocol | protocol<br/>request_protocol | HTTP protocol version
request_query | Request query | request_query | URL request query parameters (located in the latter sections of the request URL)
request_url| Request URL | request_url | String with the host, scheme, path, and query parameters for the request
response_content_type | Response content type | content_type<br/>response_content_type | Contents of the Content-Type response header
server_address | Server address | server_address | Application server address used to fulfill the request
server_latency | Server latency | server_latency | Interval between when the server received the request and the browser received the last byte of the response
session_id | Session ID | session_id | Unique ID that a server assigned to a specific user for a session
status_code | Status code | response_status_code<br/>status_code | Response status code that indicates if the specific request successfully completed
threat | Threat | threat | "y" if the IP address was a potential attacker. "n" otherwise.
tls_cipher | TLS cipher | tls_cipher | Encryption algorithms for transport layer security
tls_version | TLS version | tls_version<br/>tls_protocol | Highest version of the transport layer security protocol that the client supported
trust | Trust | Indicator of trust for a downstream proxy
ttfb | TTFB | ttfb<br/>time_to_first_byte | Interval between when the data plane received the request and sent the first byte of the response
url_map | URL map | url_map | Name of the url map used in a web control that resulted in the request being redirected
useragent | User agent | useragent<br/>user_agent | Contents of the User-Agent request header
useragent_device | User agent device | useragent_device<br/>user_agent_device | Device type used to make the request (e.g., smartphone, desktop, etc.)
useragent_name | Browser | browser<br/>useragent_name<br/>user_agent_name | Browser type used to make the request (e.g., Google Chrome, Safari, etc.)
useragent_os | User agent OS | useragent_os<br/>user_agent_os | Operating system type used to make smartphone request (e.g., Android, Mac, etc.)
webcontrols | Web controls | webcontrols | List of web controls that ran for this request |

---

## Cache source codes

The two-letter cache source codes identify the actions that the cache_source log attribute indicates.

Source Code | Explanation |
----------|----------|
| `NE` | "Not Eligible" — Request did not match any site cache conditions and pagespeed did not cache it |
| `PH` | "Pagespeed Hit" — Request was served from the cache when optimization was turned on and the resources required to render the page were present in the cache |
| `PM` | "Pagespeed Miss" — Request was not served from the cache when optimization was turned on and the resources required to render the page were not present in the cache |
| `PF` | "Pagespeed Fill" — Request initiated a pagespeed fill when optimization was turned on and the resources required to render the page were seen for the very first time |
| `SH` | "Site Cache Hit" — Request was served from the cache when the site cache was turned on and the request matched a site cache condition which was present in the cache |
| `SM` | "Site Cache Miss" — Request was not served from the cache when site cache was turned on and the request matched a site cache condition which was not present in the cache |
| `SF` | "Site Cache Fill" — Request initiated a site cache fill when site cache was turned on and the request matched one of the site cache conditions for the very first time |
| `VH` | "Varnish Hit" — Request was served from a Vinyl/Varnish cache |
| `VM` | "Varnish Miss" — Request was served through a Vinyl/Varnish cache and is cacheable but was not in cache |
| `VP` | "Varnish Pass" — Request was served through a Vinyl/Varnish cache but VCL requested to bypass cache |

___

## Delivery status codes

The delivery status codes identify how the response was generated. All non-zero values of these codes signify that the Webscale proxy server intercepted the request.

Status Code | Description |
---------:|----------|
| **0** | Request fulfilled by an application server |
| **1** | Request rejected because the source IP address was in the blacklist |
| **2** | Request rejected due to the activated WAF rule that the user uploaded |
| **3** | Request rejected because it was sitting in the suspended queue for a time equal to or greater than `maximum_queue_time` |
| **4** | Request rejected because the proxy could not process the request since the suspended queue was full |
| **5** | Shield mode turned on. The request was presented with the captcha page. |
| **6** | Shield mode turned on. The client successfully validated the captcha page. |
| **7** | Shield mode turned on. The user made an unsuccessful attempt to verify the captcha. |
| **8** | Shield mode turned on and the client presented an invalid token. The request was presented with the captcha page. |
| **9** | Request denied by the **Deny Request** web control action |
| **10** | Request redirected by the **Redirect Request** or **Redirect Using Map** web control action  |
| **11** | Request had a `mod_pagespeed_beacon` |
| **12** | Internal request |
| **13** | Request satisfied by Amazon Cloudfront |
| **14** | Request is satisfied from the proxy. This includes but is not necessarily limited to:<ul><li>`421` Misdirected errors where the SNI host does not match HTTP header host</li><li>`502` Bad gateway when the backend cannot be connected</li><li>`404` Not found when path contains escaped slashes (%2F)</li><li>`200` Delivering robots.txt from the CDN hostname (vhost)</li><li>`405` Method not allowed for TRACE method requests</li><li>`400` Bad request for bad URLs</li><li>`403` Backend certificate could not be validated</li></ul> |
| **15** | Request that is responsible for filling the cache in case of a miss |
| **16** | Request that can be satisfied from the cache now or in the future: <ul><li>If the page was cached, the request is satisfied from the cache</li><li>If the page was not cached, a fill request will be initiated to fill the cache</li></ul> |
| **17** | Request had a bad port number	|
| **18** | Request is satisfied by the microsite |
| **19** | Role-based access control: User redirected to the Webscale Control Panel page to authenticate |
| **20** | Role-based access control: Successful authentication. User did have the necessary role. |
| **21** | Role-based access control: Unsuccessful authentication. User did not have the necessary role. |
| **22** | Client-closed connection (`499` status code) This often happens when a server takes significant time to delivery a reply to a client request and the client gives up and closes their browser or presses the reload button. Because this request is already in progress, it cannot always be canceled and so it will be logged separately, and often with success. |
| **23** | Request is a content security policy violation report. |
| **24** | Delivery from serverless handler. |
| **25** | Bad content was received in proxy header (`X-Forwarded-For`). |

---

## Further Reading
- [The Webscale Control Panel Dashboard](/docs/overview/dashboard/)
- [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
- [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
- [Security How-Tos](/docs/how-tos/security/)
---
# CloudEDGE CDN Overview
URL: https://docs.webscale.com/docs/how-tos/cloudedge/cdn-overview/
Description: Introduction to CloudEDGE CDN



Content Delivery Networks (CDN) enhance a website’s performance and page load time by caching assets across multiple edge locations in the cloud. (The edge is the network location closest to where the user's browser connects to Webscale.) These locations are geographically distributed for a quicker delivery of static assets and cacheable API content to users from the location that is closest to them.

Assets include static content, such as images, CSS, and JavaScript as well as media content like videos. When a user wants to access assets, their web browser generates an HTTP request. If the assets are cached and available, the CDN serves them directly, forgoing a request to the application servers and reducing response time.

The speed of cloud provider networks and their global CDN Points of Presence (PoPs) enable quick delivery of your assets no matter where your customers are. Since assets are easily available for your application, web pages load quickly. This promotes a positive user experience and high Core Web Vitals score.

## Overview

With CloudEDGE CDN (also known as Webscale CDN), the CDN provider is incorporated into the delivery path of your application. By routing all traffic through the provider, Webscale can securely manage requests and responses for the application. As with the Webscale Site Cache feature where proxies selectively cache content, Webscale CDN can set caching policies for traffic that traverses the Webscale CDN cache.

If the Webscale CDN cache does not contain the requested assets or a request does not match the criteria of Webscale CDN caching policy, Webscale CDN sends it to origin for servicing.

## Benefits

Webscale CDN includes the following functionality.

- Advanced security
- High availability
- High performance

The improved performance and user experience is connected to higher Core Web Vitals rankings.

In conjunction with Webscale CDN, Webscale CloudEDGE workers provide a solution that enables you to run custom JavaScript code at various key points in the traffic pipeline, including before the traffic hits the application and after the application has responded.

Webscale CloudEDGE is a distributed computing platform that simplifies the global delivery of web applications and services, securely executing code close to your customers at scale. This translates into responsive websites with healthy Core Web Vitals and a polished user experience.

## Further reading

- [Configuring Webscale CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/)
- [HTTP Headers and Status Codes](/docs/Reference/http-headers/)
- [Enabling Webscale CDN](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/)
---
# Introduction to Configuring CloudEDGE CDN
URL: https://docs.webscale.com/docs/how-tos/cloudedge/cdn-configuration/
Description: Introduction to configuring CloudEDGE CDN



CloudEDGE CDN (also known as Webscale CDN) offloads cachable assets from web servers to CDN providers. In addition, it provides advanced security and near real-time logging to track performance and ensure Webscale CDN is running smoothly.

Configuring Webscale CDN for an application consists of the following stages.

- [Fulfill pre-requisites](/docs/how-tos/CloudEDGE/cdn-config-prereqs/)
- [Enable Webscale CDN](](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/#enable-webscale-cdn)
- [Configure accelerators](](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/#configure-accelerators)
- [Set up caching policies](](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/#set-up-caching-policies)
- [Validation](](/docs/how-tos/CloudEDGE/cdn-config-prereqs/#pre-requisite-validation)

If you change your mind about enabling Webscale CDN, you can roll back the configuration.
---
# Pre-requisites for Configuring CloudEDGE CDN
URL: https://docs.webscale.com/docs/how-tos/cloudedge/cdn-config-prereqs/
Description: Pre-requisites for configuring CloudEDGE CDN



Before enabling CloudEDGE CDN (also known as Webscale CDN) ensure that you meet the following pre-requisites in the order presented below.

- [Set up DNS](#set-up-dns)
- [Set up TSL](#set-up-tls)
- [Consider disabling pagespeed](#consider-disabling-pagespeed)
- [Create an admin subdomain](#create-an-admin-subdomain)
- [Provider setup](#provider-setup)
- [Pre-requisite validation](#pre-requisite-validation)

{{% alert title="Note:" %}}
While the Webscale Provisioning team has most likely already handled some of these tasks, verify that your system meets the pre-requisites.
{{% /alert %}}

## Set up DNS

1. Create aliases for all domains under the application. For information on how to view, add, and delete application aliases, see [Application aliases](](/docs/how-tos/general/app-general-settings/#application-aliases) in [Configuring General Application Settings](/docs/how-tos/general/app-general-settings/).

{{% alert title="Note:" %}}
For aliases that you would like to include in your CloudFront CDN installation, select the corresponding **CDN** checkbox for each alias. For aliases exclusive to Webscale, make sure the corresponding checkboxes are cleared.
{{% /alert %}}

2. Ensure that all domains under the application point toward Webscale, including top-level domains.
3. Verify that the DNS entries are correct.
4. Use the proxy hostname to create a CNAME for it.

## Set up TLS

Then, either provide your own certificate, or set up TLS (Transport Layer Security) by enabling the Auto HTTPS feature for your application through the **HTTPS** page. When Auto HTTPS is enabled, Webscale automatically obtains and installs [Let's Encrypt](https://letsencrypt.org) SSL certificate for the application.

For information on how to enable Auto HTTPS, see [Enable the Auto HTTPS feature](](/docs/how-tos/security/install-ssl/#enable-the-auto-https-feature) in [Installing SSL](/docs/how-tos/security/install-ssl/).

{{% alert title="Note:" %}}
If Let's Encrypt does not automatically obtain your certificate within a few hours, contact [support](mailto:support@webscalenetworks.com).
{{% /alert %}}

## Consider disabling PageSpeed

PageSpeed may interfere with desired CDN caching.  Consider diabling pagespeed to avoid a disconnection between PageSpeed enabled paths, and CDN control paths.  When PageSpeed is enabled for the same path as a CDN cachable path, PageSpeed will take priority and bypass the CDN Cache.

To disable PageSpeed for your application, navigate to the **PageSpeed** tab and toggle the feature off. Otherwise, you can disable the PageSpeed feature conditionally using Web Controls.

Web Controls enable you to configure and disable specific PageSpeed features. If you do not already have a Web Control to configure PageSpeed, create a Web Control to disable it. For information on how to create a Web Control, see [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).

When creating or modifying a Web Control to disable PageSpeed, add or make sure that your Web Control has an action with the **Set pagespeed options** action type. In the **Do you want pagespeed to run?** drop-down menu, select **No**.

{{< figure src="/images/disable_pagespeed_cdn_config.png" width="50%" alt="Disable pagespeed" >}}

{{% alert title="Note:" %}}
Make sure that the Web Control to disable PageSpeed is above all other Web Controls with final actions to ensure PageSpeed is disabled for every request.
{{% /alert %}}

## Create an admin subdomain

If requests take longer than 180 seconds to execute, they will time out. This is a CloudFront limitation. The workaround is to bypass the admin domain from CloudFront. The first step is to separate the admin domain by creating an admin subdomain.

After you enable Webscale CDN, you may point the admin subdomain to an `origin-` prefixed domain `origin-xyz.cloudmaestro.net` where `xyz.cloudmaestro.net` is the cname of the application.

For example, if the application is <span>www.webscale.com and the cname is abc.cloudmaestro.net, the admin subdomain will point to origin-abc.cloudmaestro.net.

Contact [support](mailto:support@webscalenetworks.com) to find out if this procedure applies to you.

{{% alert title="Note:" %}}
If you are accessing the admin page using a subdomain, you can use that subdomain for enabling Webscale CDN instead of creating an admin subdomain.
{{% /alert %}}

{{% alert title="Note:" %}}
Ensure you verify the correct admin domain is configured in any Web Controls that enhance security of the admin subdomain.
{{% /alert %}}

## Provider setup

### To setup a Section CDN provider

Use a shared Section CDN provider.  When enabling Webscale CDN, one will be available in the CDN provider dropdown.

If a shared Section CDN provider is unavailable, see [Section](](/docs/how-tos/general/providers/#section) in [Creating providers](](/docs/how-tos/general/providers/#create-providers).

### To setup an Amazon Cloudfront CDN provider

When you are using Webscale CDN with CloudFront for an application, your account must have a Webscale provider with the `Amazon` cloud provider type. To set up the provider so it will support Webscale CDN, perform the following procedure.

- Create a S3 bucket through AWS
- Create a Webscale provider for your account with the Amazon EC2 cloud provider type

The S3 bucket will contain your Webscale CDN logs. When you create the provider, make sure that the provider can use Webscale CDN by selecting the **Use for CDN** checkbox in the **Add a new provider** dialog box. After you select the checkbox, you must also enter the S3 bucket name.

For information on how to add a provider, see [Create providers](](/docs/how-tos/general/providers/#create-providers) in [Working with Providers](/docs/how-tos/general/providers/).

For information about Amazon cloud provider type settings, see [Amazon](](/docs/how-tos/general/providers/#amazon) in [Provider settings](](/docs/how-tos/general/providers/#provider-settings).

For information on how to add an AWS S3 bucket, see [Creating a Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html).

## Pre-requisite validation

After you have finished working on the pre-requisites, validate that you have followed all of the instructions correctly and fulfilled all of the pre-requisites.

{{% alert title="Note:" %}}
One important validation step is to make sure that your SSL certificate covers all aliases before enabling Webscale CDN, particularly if you have added new aliases after enabling Auto HTTPS. (Let's Encrypt should automatically update the certificate with any new aliases. Make sure that it does.)

There is one exception. Do not create an alias for the admin sub-domain until after you have enabled Webscale CDN.

After Webscale CDN is enabled, HTTP challenges will fail for any new aliases added to the list, so only DNS challenges will work for those challenges.
{{% /alert %}}

## Further reading
- [Introduction to Configuring Webscale CDN](/docs/how-tos/CloudEDGE/cdn-configuration/)
- [Completing Webscale CDN Configuration](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/)
- [Configuring Trusted Proxies](/docs/how-tos/advanced/trusted-proxies/)
- [Introducing HTTPS Headers and Status Codes](/docs/Reference/http-headers/)
- [Installing SSL Certificates](/docs/how-tos/security/install-ssl/)
- [Web Controls How-To Guides](/docs/how-tos/web-controls/)
- [Working with Providers](/docs/how-tos/general/providers/)
---
# CodeDirect
URL: https://docs.webscale.com/docs/how-tos/codedirect/
Description: Guides on using CodeDirect


---
# Deployment
URL: https://docs.webscale.com/docs/how-tos/deployment/
Description: Deployment Guides


---
# CloudEDGE How-To Guides
URL: https://docs.webscale.com/docs/how-tos/cloudedge/
Description: Guides on using CloudEDGE products through the Webscale Control Panel


---
# Completing CloudEDGE CDN Configuration
URL: https://docs.webscale.com/docs/how-tos/cloudedge/cdn-config-finalsteps/
Description: Complete CDN Configuration



After you fulfill the configuration pre-requisites, complete the final steps for configuring CloudEDGE CDN (also known as Webscale CDN).

The final steps consist of the following tasks.

- [Enable Webscale CDN](#enable-webscale-cdn)
- [Bypass the CDN admin domain, if needed](#bypass-the-cdn-admin-domain)
- [Set up caching policies](#set-up-caching-policies)
- [Configure accelerators](#configure-accelerators)
- [Validate the configuration](#validate-the-configuration)

If you decide to [roll back](#rolling-back-the-configuration) Webscale CDN, doing so is a simple process.

## Enable Webscale CDN

You can enable Webscale CDN through the **CDN** page for the application. The CDN delivery options determine how Webscale will use CDN.

After you confirm changes to the Webscale CDN delivery, the following changes occur.

- A "Configure CDN" task will be generated.  You may follow the task to track the progress of a newly created CDN as it is being configured on an application.
- All traffic for the application first passes through the CDN provider
- When using CloudFront, the application has a Cloudfront distribution
- When using Section, the application has a Section project
- The CDN origin will become *origin-\<application ID>.cloudmaestro.com*, which resolves to Webscale proxy addresses
- All requests will reflect the application alias and not the cloudmaestro domains

By default, CDN is disabled. Without CDN, PageSpeed is disabled and the CDN provider is unavailable.

The other CDN delivery method is to have PageSpeed rewrite to CDN. With this legacy option, Pagespeed rewrites to CDN and uses the cloudmaestro domain to deliver content to customers.

### To enable Webscale CDN

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Edit**.

    {{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/access_edit_action_menu.png" alt="Select edit application" >}}
2. On the sidebar menu, click **CDN**.

    The **CDN** page displays with the default delivery option of **Without CDN** selected.

     {{< figure src="/images/cdn/cdn-page.png" alt="CDN page" >}}

3. In the **Delivery** drop-down menu, select **Webscale CDN**.
    The **Provider** drop-down menu displays. It lists all of the providers enabled for Webscale CDN.

4. Select the CDN provider you want to use with Webscale CDN for this application.

5. Click **Apply** to enable Webscale CDN.

    {{< figure src="/images/cdn/cdn-apply-enable.png" alt="CDN page" >}}

## Bypass the CDN admin domain

If you need to bypass the CDN admin domain to prevent requests from timing out, you can complete the bypass process after enabling Webscale CDN.

Doing so points all admin traffic to *origin-\<application ID>.cloudmaestro.com*, which is your Webscale hostname.

There are different bypass procedures for new and existing customers.

### To bypass the CDN admin domain for new customers

1. While working on fulfilling configuration pre-requisites, create an admin sub-domain. For more information, see [Create an admin subdomain](](/docs/how-tos/CloudEDGE/cdn-config-prereqs/#create-an-admin-subdomain) in [CDN Configuration Pre-requisites](/docs/how-tos/CloudEDGE/cdn-config-prereqs/).
2. Enable Webscale CDN.
3. Through your application, add an alias for the admin sub-domain. For more information about adding an alias, see [Application aliases](](/docs/how-tos/general/app-general-settings/#application-aliases).
4. Point the admin sub-domain to *origin-\<application ID>.cloudmaestro.com* using DNS.

### To bypass the CDN admin domain for existing customers

1. While fulfilling configuration pre-requisites, create an admin sub-domain.
2. Enable Webscale CDN.
3. After *origin-\<application ID>.cloudmaestro.com* resolves to your proxy IP address, point your admin sub-domain to it.
4. Through your application, add an alias for the admin sub-domain.

## Configure accelerators

{{% alert title="Note:" %}}
CDN Accelerators are only available for Section CDN Providers.
{{% /alert %}}

Subscriptions for CDN accelerators may be set up to optimize edge delivery performance.  [Contact Support](mailto:support@webscalenetworks.com) to enable accelerators for your application.

CDN Accelerators are a game-changer for websites that demand fast, personalized content delivery. Accelerators enhance user experiences and help you stay competitive in today's fast-paced digital landscape.

### Magento Varnish

Magento Varnish is a specialized CDN accelerator designed to enhance the performance and caching capabilities of your Magento e-commerce website. This accelerator is specifically tailored to work seamlessly with Magento applications, ensuring that your online store delivers fast and reliable content to your customers.

The Magento Varnish accelerator is designed to work in tandem with a [Webscale varnish magento module](https://github.com/webscale-networks/magento-varnish-api) to make integration easy.

### HTML Streaming

HTML Streaming is a cutting-edge CDN accelerator that offers lightning-fast response times and advanced caching techniques. This feature is designed to optimize the delivery of HTML content, making it ideal for websites where delivering dynamic, personalized, or frequently changing content quickly is essential.

The HTML streaming accelerator offers Edge-Side Includes (ESI) support. ESI is a powerful tool that pairs with Webscale CDN allowing you to cache parts of your web pages separately. HTML Streaming fully supports ESI, enabling you to cache and serve specific components of your web pages independently. This means you can cache reusable elements while keeping dynamic sections up to date.

HTML Streaming employs intelligent caching strategies to serve cached content when possible and fetch dynamic content when necessary. It helps reduce server load and ensures that your visitors experience fast load times for both cached and dynamic elements.

### Custom VCL

Custom VCL (Varnish Configuration Language) is a powerful feature that provides users with complete control over how requests and responses are handled at the CDN's edge servers.  It allows you to tailor Webscale CDN's behavior to suit your specific needs and customize the caching, routing, and processing of content.  Custom VCL may be uploaded using the File browser

For more information on Files, check out [working with files](/docs/how-tos/general/files/).

## Set up caching policies

By default, Webscale CDN does not cache pages and resources. Every application is different, so ensure you tailor CDN controls to your specific caching needs.  After enabling Webscale CDN, create necessary CDN controls to define basic caching policies. Doing so completes Webscale CDN configuration.

On the **CDN** page, add necessary CDN controls to complete Webscale CDN configuration.  Generally, one CDN control is configured for caching media assets, and a second for static assets.

For information on Webscale CDN caching, see [Configuring CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

### Add CDN controls for media and static assets

Specify paths for caching media and static assets. When enabling Webscale CDN, create CDN controls with the following paths. Each path points to the asset location. Use wild cards when specifying paths. Save and apply the CDN controls after specifying the following settings.

- Use */media/** as the path for caching media assets.
- Use */static/** as the path for static assets.

Enter *86400* as the default TTL for both CDN controls. TTL, an acronym for Time to Live, specifies how long (in seconds) an asset will be cached before it needs to be fetched again.

## Validate the configuration

After you complete the final steps, perform a validation check to ensure that Webscale CDN delivers all assets. Using developer tools, examine a static asset. Check the asset’s X-Cache header to verify that `Hit from Cloudfront` displays for it.

After you set up caching policies, Webscale CDN does not immediately start caching. The request with the static asset might initially be a miss from CloudFront. After you re-load the page, it should be a hit.

## Rolling back the configuration

To roll back Webscale CDN, delete all CDN Controls on the **CDN** page. Doing so reinstates the default caching policy for Webscale CDN to not cache anything. Traffic still passes through Webscale CDN.

## Further reading
- [Introduction to Configuring Webscale CDN](/docs/how-tos/CloudEDGE/cdn-configuration/)
- [Pre-requisites for Configuring Webscale CDN](/docs/how-tos/CloudEDGE/cdn-config-prereqs/)
- [Configuring CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/)
- [Configuring Application General Settings](/docs/how-tos/general/app-general-settings/)
- [Working with Providers](/docs/how-tos/general/providers/)
---
# Configuring CloudEDGE CDN Caching Policies
URL: https://docs.webscale.com/docs/how-tos/cloudedge/cdn-controls/
Description: Configure CloudEDGE CDN caching through CDN controls



After you enable CloudEDGE CDN (also known as Webscale CDN) for your application, you can use the Webscale Control Panel to configure caching policies through CDN controls. These policies  define how Webscale CDN processes requests and responses, including what happens when Webscale CDN forwards requests to your application.

CDN controls allow you to run custom JavaScript at key points of the traffic pipeline via the CloudEDGE Workers feature, including as traffic transits to your application and after your application generates a response. This allows for easy extension to the capability of your application without changing your deployed code. For more information about the CloudEDGE Workers feature, see [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/).

{{% alert title="Note:" %}}
CloudEDGE Workers are only available for Amazon CDN providers.
{{% /alert %}}

## Topics

- [Webscale CDN caching](#webscale-cdn-caching)
- [CDN controls basics](#cdn-controls-basics)
- [Specify optional settings](#specify-optional-settings)
- [Change order of CDN controls](#change-order-of-cdn-controls)
- [CloudEDGE Workers](#cloudedge-workers)
- [Work with CDN controls](#work-with-cdn-controls)
     - [Access CDN controls](#access-cdn-controls)
     - [Create CDN controls](#create-cdn-controls)
     - [Modify CDN controls](#modify-cdn-controls)
     - [Reorder CDN controls](#reorder-cdn-controls)
     - [Delete CDN controls](#delete-cdn-controls)

## Webscale CDN caching

Webscale CDN uses your CDN provider to cache static resources from your applications. All HTTP requests and responses pass through the Webscale CDN cache even if they are not cachable.

You can use CDN controls to configure caching policies for Webscale CDN. Each CDN control defines how Webscale CDN responds to a particular incoming request. When you create CDN controls, you define policies that determine how and what Webscale CDN caches.

### Caching with CDN controls

With CDN controls, Webscale CDN checks the path of the request path along with its cache key to determine if the resource exists in its cache. If the CDN cache contains it with the matching cache key, Webscale CDN serves the response. (A cache key is a combination of select headers, cookies and query string values from the request.)

If the Webscale CDN cache does not contain the resource, Webscale CDN forwards the request to your application to retrieve the resource. If Site Cache does not have the resource, it forwards the request to your web servers. After Site Cache or your web servers locates the resource and serves it, Webscale serves it to the user browser. Also, Webscale caches the resource and its cache key.

### Caching without CDN controls

By default, there are no CDN controls for Webscale CDN. Without CDN controls, Webscale CDN does not cache assets and forwards all HTTP requests to your application. If you have enabled the Webscale Dynamic Site Cache feature for your proxies, Site Cache caches resources [according to its own caching policies](/docs/how-tos/advanced/site-cache/). It determines if the resource exists in its cache by converting the request into a cache key. If Site Cache contains the resource, Webscale serves the response from there. If Site Cache does not have the resource, Webscale forwards the request to your web servers.

## CDN controls basics

The configuration of each CDN control must include a request path. When Webscale CDN receives a request, it compares the request path to the CDN control paths. It selects the first CDN control that matches according to the order in which they are configured in the Webscale Control Panel.

If Webscale CDN finds a match, it uses the cache key configuration of that CDN control to generate a cache key. Webscale CDN then uses this key, along with the full path to the resource, to search in its cache.

- If Webscale CDN finds the resource and it has not expired, a cache "hit" occurs and it returns the resource.
- If Webscale CDN does not find the resource or it has expired, a cache "miss" occurs and it forwards the request to your application or, if applicable, to your web servers. The forwarded request only includes the headers, cookies, and query parameters that the CDN control configuration included. These may be different than the headers, cookies and query parameters used to create the cache key.

Optionally, you can specify the following configuration settings.

- Duration of time that a resource can be cached before it expires
- How Webscale CDN generates the cache key for a request
- Headers, cookies, and query parameters that Webscale CDN includes on the application request

## Specify optional settings

Webscale CDN uses the cache key to access the cache. It then determines if the cache contains the appropriate resource for the request. If the cache has the resource and it has not expired, Webscale CDN serves the cached resource.

CDN control settings can also determine the HTTP headers, cookies, and query parameters that Webscale CDN includes on requests that it sends to your application servers after cache misses.

If the path of a request does not match the path of any CDN control, the default policy runs. It sends the request with all of its HTTP headers, cookies, and query parameters to origin.

## Change the order of CDN controls

If a user creates multiple CDN controls, they display in a list in the **Controls** section of the **CDN** page by creation date (oldest to newest with the oldest at the top of the list) unless you have reordered the CDN controls in the list.

When the user selects a control in the list, the control's configuration is displayed in the right pane. The configuration includes the control's path pattern; how the cache key is generated for matching requests; headers, cookies and query parameters to pass through after cache misses; and any associated CloudEDGE workers

Webscale CDN compares requests to CDN controls based on their order in the list. It searches from top to bottom to find a match.

## CloudEDGE Workers

Through the CloudEDGE Workers feature, CDN controls optionally allow you to augment a request that Webscale CDN forwards to origin after a cache miss or a response that origin returns to Webscale CDN.

Custom JavaScript enables you to extend your application's functionality without changing your application code. The JavaScript source files include functions, each of which can process requests or responses but not both. The file that includes your JavaScript source files is known as a handler file. A handler incorporates the handler file.

When configuring a CDN control, you can associate up to two handlers with the control (one for requests and the other for responses). Associating handlers with a control creates a worker that runs the JavaScript function.

You can use the Webscale Image Manager feature with Webscale CDN. It automatically optimizes and processes images while maintaining image quality. Image Manager also helps embed images in your website and mobile applications to drive user engagement.

## Work with CDN Controls

You can create, modify, and delete CDN controls through the **Controls** section of the **CDN** page for your application. The **Controls** section only displays after you enable Webscale CDN. For more information on how to enable Webscale CDN, see [Introduction to Configuring Webscale CDN](/docs/how-tos/CloudEDGE/cdn-configuration/) and  [Completing Webscale CDN Configuration](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/).

## Access CDN controls

The **CDN** page for your application enables you to access CDN controls.

### To access CDN controls settings

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Edit**.

    {{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/access_edit_action_menu.png" align="left" width="45%" alt="Select edit application" >}}

2. On the sidebar menu, click **CDN**.

    When you have enabled Webscale CDN, the **Controls** section displays in the **CDN** page.

   {{< figure src="/images/cdn/cdn_controls_section.png" alt="CDN controls section" >}}

## Create CDN controls

For CDN controls, enter a path for caching assets. All other settings are optional.

When you create a CDN control, you can optionally associate the CDN control with CloudEDGE request and response handlers. Doing so creates a CloudEDGE worker.

For more information on CloudEDGE workers, see [Workers overview](](/docs/how-tos/CloudEDGE/handlers_workers/#workers-overview) in [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/).

#### To create a CDN control

1. On the **CDN** page, click the **Add control** link in the **Controls** section.

   {{< figure src="/images/cdn/cdn_control_add_control_link.png" alt="Click Add control link" >}}

2. In the **Add control** dialog box, enter the path for caching assets in the <strong>Path</strong> field. For example, to create a CDN control for media assets, enter <em>/media/*</em>.

   {{< figure src="/images/cdn/cdn_add_control_dialog_media.png" align="left" width="65%" alt="Add CDN control with media path" >}}

3. To specify the amount of time that a resource can be cached, enter a Time-to-Live (TTL) value in the **Default TTL (seconds)** field.
4. To specify cache key headers, in the **Headers** drop-down menu of the **Cache key configuration** section:</br>
     a. Select **Include specified** for an option other than the default setting of not having any  headers.</br>

     {{< figure src="/images/cdn/cdn_controls_select_cache_header.png" align="left" width="70%" alt="Select Include specified header option for cache key headers" >}}

     b. Click the **Add headers** link.</br>

     {{< figure src="/images/cdn/cdn_controls_click_add_headers_link.png" align="left" width="65%" alt="Click Add headers link" >}}

     c. Click in the **Add Headers** field to open the drop-down menu:</br>
         Select a header from the drop-down list.</br>
         -or-</br>
         Enter a header.</br>
      d. Click **Add**. </br>

     {{< figure src="/images/cdn/cdn_control_add_header.png" align="left" width="65%" alt="Click Add" >}}

      e. To add more headers, repeat one of these procedures for each header.
5. To specify cache key cookies, in the **Cookies** drop-down menu of the **Cache key configuration** section:</br>
     a. Select **Include specified** or **Exclude specified** for an option other than having all or no cookies.</b></br>
     b. Click the **Add cookies** link.</br>
     c. In the **Add cookies** field, enter a cookie.</br>
     d. Click **Add**.</br>
     e. To add more cookies, repeat this procedure for each cookie.
6. To specify cache key queries, in the **Queries** drop-down menu of the **Cache key configuration** section:</br>
     a. Select **Include specified** or **Exclude specified** for an option other than having all or no queries.</br>
     b. Click the **Add queries** link.</br>
     c. In the **Queries** field, enter a query.</br>
     d. Click **Add**.</br>
     e. To add more queries, repeat this procedure for each query.
7. To specify origin request headers, in the **Headers** drop-down menu of the **Origin request configuration** section:</br>
     a. Select **Include specified** for an option other than the default setting of having no headers.</br>
     b. Click the **Add headers** link.</br>
     c. Click in the **Add headers** field to open the drop-down menu:</br>
         Select a header from the drop-down list.</br>
         -or-</br>
         Enter a header.</br>
     d. Click **Add**.</br>
     e. To add more headers, repeat this procedure for each header.
8. To specify origin request cookies, in the **Cookies** drop-down menu of the **Origin request  configuration** section:</br>
     a. Select **Include specified** for an option other than having all or no cookies.</br>
     b. Click the **Add cookies** link.</br>
     c. In the **Add cookies** field, enter a cookie.</br>
     d. Click **Add**.</br>
     e. To add more cookies, repeat this procedure for each cookie.
9. To specify origin request queries, in the **Queries** drop-down menu of the **Origin request configuration** section:</br>
     a. Select **Include specified** for an option other than having all or no queries.</br>
     b. Click the **Add queries** link.</br>
     c. In the **Queries** field, enter a query.</br>
     d. Click **Add**.</br>
     e. To add more queries, repeat this procedure for each query.
10. To associate the CDN control with a request handler, select the handler in the **When processing an origin request** drop-down menu in the **CloudEDGE Workers** section.

{{% alert title="Note:" %}}
CloudEDGE Workers are only available for Amazon CDN providers.
{{% /alert %}}

11. To associate the CDN control with a response handler, select the handler in the **When processing an origin response** drop-down menu in the **CloudEDGE Workers** section.

    {{< figure src="/images/handlers/cdn_control_add_handlers.png" align="left" width="65%" alt="Select handlers for a CDN control" >}}

12. Click **Save**.

    {{< figure src="/images/cdn/cdn_control_click_save_new.png" align="left" width="65%" alt="Click Save" >}}

13. In the **CDN** page, click **Apply**.

     {{< figure src="/images/cdn/cdn_control_click_apply_new_control.png" align="left" width="100%" alt="Click Apply" >}}

## Modify CDN controls

You can modify a caching policy by specifying different settings for the associated CDN control. While you can change all settings, there must be a valid path for caching assets in the **Path** field.

#### To modify a CDN control

1. In the **CDN** page, select a CDN control in the **Path** panel of the **Controls** section.
The settings for the CDN control display in the **Control details** pane.
2. Click the **Edit control** icon <i class="fas fa-edit" aria-hidden="true"></i> for the CDN control.

     {{< figure src="/images/cdn/cdn_control_click_edit_icon.png" align="left" width="100%" alt="Click Edit control icon" >}}

3. In the **Edit control** dialog box, modify settings.

     {{< figure src="/images/cdn/cdn_control_edit_dialog.png" align="left" width="65%" alt="Edit CDN control" >}}

4. Click **Save**.
5. In the **CDN** page, click **Apply**.

## Reorder CDN controls

The order of the CDN controls in the **Path** pane determines when Webscale compares requests to the CDN control. It searches from the top CDN control to the bottom to find a match.

#### To reorder CDN controls

1. In the **Path** pane of the **Controls** section, click the **Reorder controls** link.

     {{< figure src="/images/cdn/cdn_control_click_reorder_link.png" align="left" width="100%" alt="Click Reorder controls link" >}}

2. In the **Reorder controls** dialog box, drag-and-drop CDN controls in the list to to change the order in which Webscale runs through them.

     {{< figure src="/images/cdn/cdn_control_reorder_controls_dialog.png" align="left" width="85%" alt="Drag-and-drop CDN control" >}}

3. Click **Save**.
4. In the **CDN** page, click **Apply**.

## Delete CDN controls

After you delete a CDN control, it no longer displays in the list of CDN controls in the **Path** pane of the **Controls** section.

#### To delete a CDN control

1. In the **CDN** page, select a CDN control in the **Path** panel of the **Controls** section.
The settings for the CDN control display in the **Control details** panel.
2. Click the **Delete control** icon <i class="fas fa-trash-alt" aria-hidden="true"></i> for the CDN control.

     {{< figure src="/images/cdn/cdn_control_click_delete_icon.png" align="left" width="100%" alt="Click Delete control icon" >}}

3. In the **CDN** page, click **Apply**.


## Further reading
- [HTTP Headers and Status Codes](/docs/Reference/http-headers/)
- [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/)
- [Introduction to Configuring Webscale CDN](/docs/how-tos/CloudEDGE/cdn-configuration/)
- [Pre-requisites for Configuring CloudEDGE CDN](/docs/how-tos/CloudEDGE/cdn-config-prereqs/)
- [Enable Webscale CDN](](/docs/how-tos/CloudEDGE/cdn-config-finalsteps/#enable-webscale-cdn)
- [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/)
- [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/)
---
# CloudEDGE Workers Overview
URL: https://docs.webscale.com/docs/how-tos/cloudedge/workers-overview/
Description: Introduction to CloudEDGE Workers



The Webscale CloudEDGE platform is a distributed cloud computing platform. It enables fast, personalized commerce and application content delivery to the edge. (The edge is the network location closest to where the user's browser connects to Webscale). The platform includes CloudEDGE CDN and CloudEDGE Workers, which you can manage through the Webscale Control Panel.

The caching policies for your application specify how CloudEDGE CDN (also known as Webscale CDN) caches resources. They determine what resources are cached, how long they are cached, and how Webscale CDN processes requests for cache misses. The CloudEDGE Workers feature expands the functionality of Webscale CDN for your application by executing custom JavaScript code on the edge.

{{% alert title="Note:" %}}
CloudEDGE Workers are only available for Amazon CDN providers.
{{% /alert %}}

{{% alert title="Note:" %}}
When Webscale CDN does not find the resource for a request, a cache “miss” occurs and it forwards the request to your application (also known as "origin").
{{% /alert %}}

For information on CloudEDGE CDN and caching policies, see [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/) and [Configuring Webscale CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

For an illustration on how to use CloudEDGE Workers, see [CloudEDGE Workers Usage Example](/docs/how-tos/CloudEDGE/workers-usage-example/).

## Topics

- [CloudEDGE Workers feature](#cloudedge-workers-feature)
- [Procedure for working with CloudEDGE Workers](#procedure-for-working-with-cloudedge-workers)
    - [Upload handler files](#upload-handler-files)
    - [Create handlers](#create-handlers)
    - [Create workers](#create-workers)
- [Worker execution](#worker-execution)

## CloudEDGE Workers feature

You can use the CloudEDGE Workers feature to easily extend your application's functionality through custom JavaScript without changing your application code. It adds programmability and on-arrival code execution to Webscale CDN. Through CloudEDGE Workers, you can modify requests before they reach your application and responses before they reach the client.

CloudEDGE Workers provides a serverless execution environment. This means developers can write custom JavaScript code once with the option to deploy to multiple cloud providers without needing to change the application code.  The CloudEDGE Workers feature takes care of writing, packaging, and distribution of the code.

The file that includes your JavaScript source files as a [NPM package](https://docs.npmjs.com/about-packages-and-modules) is known as a handler file. Each exported JavaScript function can process requests or responses (but not both) and must conform strictly to the handler interface. The handler file can have more than one function.

A handler incorporates the handler file. When you configure a handler, you choose one function from the handler file to run. The caching policy with which the handler is associated determines when the function runs. Associating a handler with the CDN control for the policy creates a CloudEDGE worker. Currently, workers execute after cache misses.

Workers can do everything from optimizing cached images to injecting security cookies.

## Procedure for working with CloudEDGE Workers

You can use the following procedure to work with handlers and workers. The Webscale Control Panel enables you to manage handlers and workers. For information on creating handlers and workers, see [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/).

- [Upload handler files](#upload-handler-files)
- [Create handlers](#create-handlers)
- [Associate handlers with CDN controls](#associate-handlers-with-cdn-controls)

### Upload handler files

Handler files adhere to the common structure used for NPM packages with some additional constraints. You can upload handler files to your account through the **Files** page. All applications for your account can then use the file for their handlers.

The **Files** page enables you to view all files in the NPM package and their contents. You can also use this page to download, replace, edit, and delete handler files.

For information about uploading files, see [Working with Files](/docs/how-tos/general/files/).

For information about creating handler files, see [Creating Handler Files](/docs/how-tos/cloudedge/create-handler-file/).

### Create handlers

When you create a handler, you configure the following settings.

- Name
- Description (optional)
- Provider
- Handler file
- Function
- Memory

When you select the provider, you can only choose a provider that has Webscale CDN and CloudEDGE Workers enabled for it.

You can only select one function for a handler. It can be either a request or response function that deploys as a request or response worker.

The memory setting specifies the maximum amount of computing resources that the provider will allocate to the worker during execution.

{{% alert title="Note:" %}}
You can create more than one handler with the same file. If the file has multiple functions, you can choose the one that you want for the handler.
{{% /alert %}}

### Create workers

Caching policies specify the workers that will run. Each CDN control for a caching policy has settings that enable you to associate handlers with the control, which results in a worker. By default, CDN controls do not have handlers associated with them. You can select a request handler, response handler, or both for a control. When creating the control, you define when the worker runs.

A worker with a request function executes before Webscale CDN forwards the request to origin. A worker with a response function runs in conjunction with the origin response.

When you have a CDN control with two handlers, the CDN control will have a worker for each type of function. For a cache miss, the request and response workers for the CDN control will both run.

### Worker execution

CDN controls determine how Webscale CDN responds to incoming requests for assets. It compares the path for each request to the request paths for your CDN controls. If Webscale CDN finds a match, it searches for the resource in its cache.

When a cache “miss” occurs, Webscale CDN forwards the request to your application and the worker with a request handler runs. When your application sends a response, the response worker executes.

## Further reading

- [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/)
- [Configuring Webscale CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/)
- [Creating Handler Files](/docs/how-tos/CloudEDGE/create-handler-file/)
- [Working with Files](/docs/how-tos/general/files/)
- [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/)
- [CloudEDGE Workers Usage Example](/docs/how-tos/CloudEDGE/workers-usage-example/)
- [HTTP Headers and Status Codes](/docs/Reference/http-headers/)
---
# CloudEDGE Workers Usage Example
URL: https://docs.webscale.com/docs/how-tos/cloudedge/workers-usage-example/
Description: CloudEDGE Workers Usage Example



CloudEDGE Workers is a feature that expands the functionality of CloudEDGE CDN for your application by executing custom JavaScript code on the edge. It is part of the CloudEDGE distributed computing platform along with CloudEDGE CDN.

Webscale CDN enhances a website’s performance and page load time by caching assets across multiple edge locations in the cloud. Webscale CDN also processes requests unrelated to caching. Since all requests pass through the Webscale CDN, CloudEDGE workers are able to execute on both cached and uncached requests.

This example is a demonstration of how you could use CloudEDGE Workers to prevent SQL Injection on a vulnerable form.

For information on CloudEDGE Workers and CloudEDGE CDN, see [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/) and [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/).

## Scenario

You have hired a consultant to evaluate your website for security vulnerabilities. They discover that one of your forms is insecure and recommend making a quick fix to immediately secure your application.

The CloudEDGE Workers feature enables you to create a CloudEDGE worker that runs to sanitize  origin requests (also known as cache misses) related to SQL databases. The JavaScript for the handler file employs escaping problematic characters to prevent SQL injection attacks. SQL injection attacks exploit vulnerabilities to inject malicious database statements and gain access to your application's database.

## Concepts

The following concepts are relevant to this example.

### CloudEDGE CDN caching

The caching policies for your application specify how CloudEDGE CDN (also known as Webscale CDN) caches resources. They determine what resources are cached, how long they are cached, and how Webscale CDN processes requests for cache misses.

CloudEDGE Workers runs custom JavaScript code for cache misses.

### CDN controls

CDN controls define caching policies for your application. Each CDN control includes a request path pattern for CDN cache locations. When the path for a request matches the path for a CDN control, Webscale CDN searches its cache for the request assets.

### Cache miss

A cache “miss” occurs when Webscale CDN does not find the resource for a request in its cache. Webscale CDN forwards requests that are cache misses to your application (also known as "origin").

### Handlers

Handler files include your JavaScript source files. The JavaScript files contain functions, each of which can process requests or responses (but not both).

Each handler is implemented in a handler file. Handlers are request or response handlers, depending on the type of function selected for the handler.

### Workers

Workers run the JavaScript code. You create workers when you associate handlers with CDN controls. When a request handler is associated with the CDN control, the worker runs before Webscale CDN forwards the request. Response workers run after your application or web servers respond to a cache miss.

If an origin response contains a resource that the Webscale CDN cache does not contain, Webscale CDN caches the resource and forwards the response to the user.

For information on workers, see [CloudEDGE workers feature](](/docs/how-tos/CloudEDGE/workers-overview/#cloudedge-workers-feature) in [CloudEDGE Workers Overview](](/docs/how-tos/CloudEDGE/workers-overview/#cloudedge-workers-overview).

For information about Webscale CDN caching and controls, see [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

### Setup

This scenario includes the following items.

- **Handler file**: Named “Sanitize.” Includes a JavaScript source file with a request function that checks the body of the origin request for single quotes (`'`).

    If a single quote is present in the body of the HTTP request, it escapes this character, replacing it with `\'`

- **Handler**: Named "Example handler." Incorporates the Sanitize handler file, which you have uploaded to the **Files** page for your account.
- **CDN controls for your application**: Three CDN controls, each of which specifies a different path, displays in the following order, and runs from top to bottom.
    - `/media/*`
    - `/static/*`
    - `*` (Example handler is associated with this control and the TTL is 0, which means that the policy is to not cache anything)
- **Worker**: Created when the Example handler is associated with the `*` CDN control

## Process

1. The user submits the form.
2. The user's browser sends a request that will perform a query on the database.
3. The request path does not match the `/media/*`; and `/static/*` request path patterns but does match the `*` path.
4. Webscale CDN does not search the cache since the policy of the final control is to not cache anything
5. Webscale CDN categorizes the request as a cache miss.
6. The JavaScript function for the worker checks the request body to find out if it contains single quotes and escapes them with `\'` if it finds this character.

{{% alert title="Note:" %}}
If the user's browser does not support WebP-formatted images, the worker adds the `webp-accepted` HTTP header with a value of `false` to the origin request. Webscale searches for and finds the image in a supported file format. It serves up a response with the image.
{{% /alert %}}

For information about creating a handler file, including JavaScript functions and the handler interface, see [Creating CloudEDGE Handler Files](/docs/how-tos/CloudEDGE/create-handler-file/).

For information about file uploading and viewing handler files, see [Working with Files](/docs/how-tos/general/files/).

### JavaScript code for the example

A JavaScript function for the Sanitize handler file specifies that the code will execute for origin requests.

```
/**
 * Should return a non-null response if the origin request should be subverted
 * @param {WSRequest} wRequest request object to be processed
 * @returns {WSRequest or WSResponse}
 */
exports.sanitizeInput = function (wRequest) {
	const reqBody = wRequest.body.data
	const reqQuery = wRequest.query

	//there is a body in the request that should be sanitized
	if (reqBody !== null) {
		var escaped = reqBody.replace("'", "\'")

		wRequest.body = {
			data: escaped,
			modified: true,
			encoding: 'text',
			truncated: false
		}

		return {
			request: wRequest
		}
	}
	//there is a query in the request that should be sanitized
	if (reqQuery !== null) {
		wRequest.query = encodeURIComponent(reqQuery);
	}

	return {
		request: wRequest
	};
}
```

## Sanitize handler file

Upload the Sanitize handler file through the **Files** page. After you upload the handler file, you can view a list of its files.

{{< figure src="/images/handlers/handlers_select_file.png" align="left" width="95%" alt="View handler files" >}}

Through the **Files** page, you can also view the contents for specific files.

{{< figure src="/images/handlers/handlers_file_contents.png" align="left" width="95%" alt="View handler file contents" >}}

After you have uploaded the Sanitize handler file, you can create a handler for your application that incorporates the file.

## Example handler

Create the Example handler for your account, specifying its name, provider, file, function, and memory. The Example handler contains an optional description that explains that it sanitizes origin requests to prevent SQL injection attacks.

For information on creating handlers and workers, see [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/).

{{< figure src="/images/handlers/handlers_example_handler.png" align="left" width="65%" alt="Example handler" >}}

## CDN control

Create CDN controls for your application with the `/media/*`, `/static/*`, and `*` request paths. When you create the control with the `*` path, associate the Example handler with it.

To do so, select the Example handler from the **When processing an origin request** drop-down menu in the **CloudEDGE Workers** section of the __Add control__ dialog box.

{{< figure src="/images/handlers/handlers_example_cdn_control.png" align="left" width="65%" alt="Handler example" >}}

## Further reading

- [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/)
- [Working with CloudEDGE Handlers and Workers](/docs/how-tos/CloudEDGE/handlers_workers/)
- [HTTP Headers and Status Codes](/docs/Reference/http-headers/)
- [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/)
---
# Working with CloudEDGE Handlers and Workers
URL: https://docs.webscale.com/docs/how-tos/cloudedge/handlers_workers/
Description: Configure CloudEDGE handlers and workers through the Webscale Control Panel



The CloudEDGE Workers feature adds programmability and on-arrival code execution to CloudEDGE CDN (also known as Webscale CDN). It extends your application's functionality using custom JavaScript without changing your application code. When you use CloudEDGE Workers, it augments a request that Webscale CDN forwards to origin after a cache miss or a response that origin returns to Webscale CDN.

The CloudEDGE Workers feature uses the following components.

- Handler files that include custom JavaScript source files
- Handlers that incorporate the handler files
- Workers that run the JavaScript code according to CloudEDGE CDN caching policies

Configuring CloudEDGE workers (also known as workers) involves the following process.

- Create a handler file with one or more JavaScript source files
- Configure a handler, which incorporates a handler file
- Associate a handler with a CDN control, which results in a worker

For more information about the CloudEDGE Workers feature, see [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/).

For more information about CDN caching, see [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

## Topics

- [Handler files](#handler-files)
    - [Uploading and other shared files procedures](#uploading-and-other-shared-files-procedures)
    - [File requirements](#file-requirements)
- [Preview handler files](#preview-handler-files)
- [Handlers overview](#handlers-overview)
    - [Access the Handlers page](#access-the-handlers-page)
    - [Create handlers](#create-handlers)
    - [View handler details](#view-handler-details)
    - [Edit handlers](#edit-handlers)
    - [Delete handlers](#delete-handlers)
- [Workers overview](#workers-overview)
    - [Create workers](#create-workers)

## Handler files

Each handler file is structured as a [NPM package](https://docs.npmjs.com/about-packages-and-modules). It includes your JavaScript source code and all of the third-party dependencies (also known as node modules) needed to run your code.

In addition, the handler package file (also known as a handler file) must include two files specific to Webscale: `package.json` and `manifest.json`. These files must exist in the root directory of the handler file.

{{< figure src="/images/handler-files/handler_file_directory_structure.png" align="left" width="95%" alt="Handler file directory structure" >}}

You must upload a handler file before you can create handlers. The **Files** page enables you to upload and manage files. With one exception, the CloudEDGE Workers feature follows the same procedures for uploading and managing files as other Webscale features that use uploaded files. The procedure for previewing handler content files is specific to CloudEDGE Workers.

For more information about CloudEDGE handler files, see [Creating CloudEDGE Handler Files](/docs/how-tos/CloudEDGE/create-handler-file/).

### JavaScript functions

For the JavaScript source files, exported functions can process requests or responses (but not both) and must conform strictly to the handler interface. A JavaScript file can have more than one function and a mix of request and response functions.

### Uploading and other shared files procedures

Webscale features that use uploaded package files, such as CloudEDGE Workers and microsites, share the same procedures for uploading and managing files. An exception is previewing content files. Working with handler and microsite files includes procedures for the following shared operations.

- [Upload files](](/docs/how-tos/general/files/#upload-files)
- [Work with uploaded files](](/docs/how-tos/general/files/#work-with-uploaded-files)
    - [Downloading](](/docs/how-tos/general/files/#download-file)
    - [Replacing](](/docs/how-tos/general/files/#replace-file)
    - [Editing file details](](/docs/how-tos/general/files/#edit-file-details)
    - [Deleting](](/docs/how-tos/general/files/#delete-file)

For more information about uploading and managing files, see [Working with Files](/docs/how-tos/general/files/).

### File requirements

Through the **Files** page, you can upload handler files. A handler file must fulfill the following requirements.

- .zip, .tar, or .tar.gz file format
- Under 50 MB in size
- `package.json` and `manifest.json` files

## Preview handler files

After you upload a handler file, you can preview its content files in the **Files** page. While previewing a handler file, you can view a list of the files that it contains, including the JavaScript, `package.json`, and `manifest.json` files and node modules, in the **Content** panel. You can also choose to view the contents of a listed file.

By previewing, you can verify that the handler file contains the correct content files. If not, you can edit, replace, or delete handler files through the shared procedures for working with uploaded files. For more information, see [Work with uploaded files](](/docs/how-tos/general/files/#work-with-uploaded-files) in [Working with Files](/docs/how-tos/general/files/).

{{% alert title="Note:" %}}
You can add or replace content files by creating or modifying a handler with the correct content files, then uploading the handler file.
{{% /alert %}}

For more information about handler content files, see [Handler files](](/docs/how-tos/CloudEDGE/create-handler-file/#handler-files) in [Creating CloudEDGE Handler Files](/docs/how-tos/CloudEDGE/create-handler-file/).

#### To preview handler files

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper-left of the screen.
2. On the sidebar menu, select **Files**.
    The **Files** page displays.

    {{< figure src="/images/files/select_files.png" align="left" width="95%" alt="Files sidebar option">}}

3. In the **Files** page, select a file in the **Files** panel.<br>
   The handler files display in the **Content** panel.

   {{< figure src="/images/handlers/handlers_select_file.png" align="left" width="95%" alt="View handler files" >}}

3. In the **Content** panel, click on a content file.<br>
   The **Preview** panel displays a preview of the file contents. For example, if a file contains JavaScript, the code will display.

    {{< figure src="/images/handlers/handlers_file_contents.png" align="left" width="95%" alt="View handler file contents" >}}

4. To return to the **Files** panel, click **Files** in the navigation path.

## Handlers overview

{{% alert title="Note:" %}}
You must create the lambda_basic_execution role for your AWS account before creating your first handler. Contact [support](mailto:support@webscalenetworks.com) for assistance or if you have questions about creating this role.
{{% /alert %}}

When you create a CloudEDGE handler for your account, you select the following items for it.

- Provider for which the CloudEDGE Workers feature is enabled
- Uploaded handler file
- Request or response JavaScript handler function

The **Handlers** page enables you to perform the following procedures. After you create a  handler for your account, it is available to all the applications in the account.

- [Access the Handlers page](#access-the-handlers-page)
- [Create handlers](#create-handlers)
- [View handler details](#view-handler-details)
- [Edit handlers](#edit-handlers)
- [Delete handlers](#delete-handlers)

### Access the Handlers page

The **Handlers** page enables you to work with handlers.

#### To access the Handlers page

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper-left of the screen.
2. On the sidebar menu, select **Handlers**. The **Handlers** page displays.

   {{< figure src="/images/handlers/access_handlers_page.png" align="left" width="100%" alt="Access Handlers page" >}}

### Create handlers

A handler is a request or response handler based on the type of JavaScript function that you select when you create the handler. As such, Webscale will use it for either requests or responses. You can create several handlers with the same handler file. If the handler file contains multiple functions, you could create a handler for each function.

Only Amazon EC2 providers that are enabled for use with CloudEDGE Workers display in the **Create handler** dialog box. For more information on configuring providers, see [Working with Providers](/docs/how-tos/general/providers/).

Handler memory refers to the memory that the cloud provider allocates to a handler function when it runs it. You can modify the amount of allocated memory according to the amount of memory that a handler function needs to run.

#### To create a handler

1. On the **Handlers** page, click the **Create handler** link.

   {{< figure src="/images/handlers/create_handlers_link.png" align="left" width="100%" alt="Click the Create handlers link" >}}

2. In the **Create handler** dialog box, enter a name and, optionally, a description.
3. Select a provider from the **Provider** drop-down menu.
4. Select a handler file from the **File** drop-down menu.
5. Select a JavaScript function from the **Function** drop-down menu. In the drop-down menu, the functions display in one of two groups: request or response functions.
6. If necessary, replace the default amount of memory in the **Memory (MB)** field.
7. Click **Save**.

   {{< figure src="/images/handlers/save_create_handler.png" align="left" width="100%" alt="Create new handler" >}}

    The handler displays in the handlers list in the **Handlers** page.

### View handler details

You can view the following details for handlers.

- Created: Handler creation timestamp
- Updated: Timestamp for the last time that you edited the handler
- Provider: Provider selected for the handler
- File Name: Handler file name
- Version: Version of the selected handler file that you specify
- Function name: Name of the JavaScript function that the cloud provider executes
- Memory: Amount of memory allocated for a handler function when a cloud provider runs it
- External reference: Cloud provider-specific URL to the function that encapsulates the  handler function
- Associated to: When you have associated the handler to a CDN control, name of the application for the CDN control

#### To view handler details

On the **Handlers** page, select a handler. Detailed information for the handler displays in the **Details** pane.

   {{< figure src="/images/handlers/view_handler_details.png" align="left" width="100%" alt="View handler detailed information" >}}

### Edit handlers

You can modify everything about a handler, including the handler file, except for its name.

When you edit a handler that is associated with a CDN control, you can select a different function for the handler. However, you can only replace it with a function that has the same type (request or response) as the current selected function.

To change the function type, remove the handler from the CDN control. Then, choose any function that you want, including one with a different function type.

#### To edit a handler

1. On the **Handlers** page, select a handler.
2. Click the edit icon <i class="fas fa-edit" aria-hidden="true"></i> for the handler.

   {{< figure src="/images/handlers/select_edit_handler_link.png" align="left" width="100%" alt="Click handler edit icon" >}}

3. In the **Edit** dialog, modify the desired settings.

   {{< figure src="/images/handlers/edit_handler_dialog.png" align="left" width="100%" alt="Edit handler" >}}

4. Click **Save**.

### Delete handlers

If a handler is associated with a CDN control, you cannot delete the handler until after you have removed it from the CDN control.

#### To a delete handler

1. On the **Handlers** page, click the delete icon <i class="fas fa-trash-alt" aria-hidden="true"></i> for a handler.

   {{< figure src="/images/handlers/handler_delete_icon.png" align="left" width="100%" alt="Click handler delete icon" >}}

2. Click **Ok**.<br>
    The file will no longer display in the **Handlers** page list.

## Workers overview

Workers run handler functions after cache misses. To create a worker, associate a handler with a CDN control when you create or edit the control. A worker with a request function executes before Webscale CDN forwards the request to origin. A worker with a response function runs in conjunction with the origin response.

CDN controls configure the Webscale CDN caching policies that determine when workers run. When configuring a CDN control, you can associate up to two handlers with the control (one for requests and the other for responses). For information about caching policies, see [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

You can configure CDN controls through the **Controls** section of the **CDN** page for your application. This section only displays after you enable Webscale CDN. For more information on Webscale CDN, see [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/).

### Create workers

This procedure provides instructions for creating workers by adding handlers while creating CDN controls.

#### To create a worker

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Edit**.

    {{< figure src="/images/access_edit_app_box.png" alt="Select edit application" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/access_edit_action_menu.png" alt="Select edit application" >}}

2. On the sidebar menu, click **CDN**. The **CDN** page displays.

3. In the **Controls** section of the **CDN** page, click on the **Add control** link.

     {{< figure src="/images/cdn/cdn_click_add_control.png" alt="Click Add control link" >}}

4. In the **Add control** dialog box, enter a path for the CDN control. Then, except for the CloudEDGE Workers settings, configure the desired optional settings.

     {{< figure src="/images/cdn/cdn_add_control_dialog_settings.png" alt="Specify CDN control settings" >}}

5. In the **CloudEDGE Workers** section, select a handler in the **When processing an origin request** drop-down menu.
6. Select a handler in the **When processing an origin response** drop-down menu.

   {{< figure src="/images/handlers/cdn_control_add_handlers.png" alt="Select handlers for a CDN control" >}}

7. Click **Save**.

## Further reading

- [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/)
- [Creating CloudEDGE Handler Files](/docs/how-tos/CloudEDGE/create-handler-file/)
- [CloudEDGE Workers Usage Example](/docs/how-tos/CloudEDGE/workers-usage-example/)
- [CloudEDGE CDN Overview](/docs/how-tos/CloudEDGE/cdn-overview/)
- [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/)
- [Working with Files](/docs/how-tos/general/files/)
---
# Creating CloudEDGE Handler Files
URL: https://docs.webscale.com/docs/how-tos/cloudedge/create-handler-file/
Description: Developer instructions for creating CloudEDGE handler files



CloudEDGE workers provide a way to augment your application by modifying the requests that it handles and the responses that it generates without the need to change your existing, deployed application code.

Handlers run your custom JavaScript code in a serverless execution environment that is agnostic to your cloud provider. They provide a uniform development environment and deployment flexibility. Additionally, handlers can run at the CDN edge, closer to your users, which allows for improved response times.

For more information about CloudEDGE Workers, see [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/).

{{% alert title="Note:" %}}
Currently, Webscale supports Amazon EC2 (also known as Amazon Elastic Compute Cloud).
{{% /alert %}}

## Topics

- [Handler files](#handler-files)
- [Writing handler functions](#writing-handler-functions)
- [CloudEDGE handler interfaces](#cloudedge-handler-interfaces)
    - [Request handlers](#request-handlers)
    - [Response handlers](#response-handlers)
- [wRequest and wResponse objects](#wrequest-and-wresponse-objects)
    - [wRequest object](#wrequest-object)
    - [wResponse object](#wresponse-object)
- [AWS property mutability](#aws-property-mutability)
- [Examples of handler functions](#examples-of-handler-functions)
- [Testing handlers](#testing-handlers)
- [Integrating the CloudEDGE handler testing framework](#integrating-the-cloudedge-handler-testing-framework)
- [Enabling the CloudEDGE Workers feature](#enabling-the-cloudedge-workers-feature)

## Handler files

A CloudEDGE handler is implemented in a handler file. The handler file is structured as a [NPM package](https://docs.npmjs.com/about-packages-and-modules). It includes your JavaScript source code and all of the third party-dependencies (also known as node modules) needed to run your code. You do not need to publish this package to the official NPM repository.

In addition to the source code and node modules, the handler file must include two files: `package.json` and `manifest.json`. These files must exist in the same directory, which is the package’s root directory.

{{< figure src="/images/handler-files/handler_file_directory_structure.png" align="left" width="95%" alt="Handler file directory structure" >}}

The [`package.json`](https://docs.npmjs.com/cli/v8/configuring-npm/package-json) file describes the dependencies of the source code, the most important of which is the [`@webscale-networks/cloudedge-handlers`](https://www.npmjs.com/package/@webscale-networks/cloudedge-handlers) node module. This Webscale node module runs your handler in a serverless execution environment once it is deployed. The environment is independent of your cloud provider. The Webscale API will reject handler files that fail to include this dependency in both the `dependencies` and `bundledDependencies` sections of their `package.json` file. Additionally, the ``@webscale-networks/cloudedge-handlers`` node module must exist at ``<root-directory>/node_modules``.

The `manifest.json` file contains metadata about the source code of your handler file. Specifically, it enumerates the handler functions contained within, where their implementations exist, and whether they process requests or responses.

#### manifest.json file specification

```
[{
    'moduleName':     a unique module name as a string,
    'relativePath':
      relative path from package root directory to the handler function source file,
    'functions': [{
        name:         function name as a string,
        type:         one of ‘handleRequest’ or 'handleResponse',
      }]
}]
```

#### Example of a manifest.json file

The following sample code is for a single manifest.json file with two handler functions.

```
[{
    'moduleName':     handlerSource,
    'relativePath':   “src/handler.js”,
    'functions': [
      {
        name:         “addsRequestHeader”,
        type:         “handleRequest”,
      },
      {
        name:         “hijacksResponseBody”,
        type:         “handleResponse”,
      },
    ]
}]
```

## Writing handler functions

Handlers that process requests are called request handlers. Likewise, handlers that process responses are called response handlers. When creating the implementation of a handler function, it is important to decide whether it should process requests or responses as the interfaces are similar but not identical.

To reiterate, a single source file can contain multiple handler functions, mixing request and response handlers. However, a single handler function cannot process both requests and responses. The function that runs depends on the handler function that an end user chooses when they create a handler through the Webscale Control Panel. For general information on working with handlers through the Webscale Control Panel, see [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/).

## CloudEDGE handler interfaces

Depending on what type of handler function you write, the function must accept different arguments.

- Request handlers must accept a single argument, representing the client’s request.
- Response handlers must accept two arguments. The first one is the client’s request and the second is the generated response.

Handler functions are not forced to return a result. One example is if the function decides not to modify the `wRequest` or `wResponse` object. If the handler function does return a result, it must be an object containing a subset of the following properties: `error`, `request`, and `response`. The `error` property, if set, should be a JavaScript error.

#### Request handlers

Request handlers can set the following properties on their returned object.

- Return a JavaScript error by setting the `error` property on the returned object. The error will be logged in the cloud provider. The cloud provider’s default error response will be returned to the client.
- Return a JavaScript error and custom response by setting the `error` and `response`  properties. The error will be logged in the cloud provider. The response will be returned to the client.
- Return a custom response by setting the `response` property
- Update the request by setting the `request` property
- Return nothing

#### Response handlers

Response handlers can set the following properties on their returned object.

- Return a JavaScript error by setting the `error` property on the returned object. The error will be logged in the cloud provider. The cloud provider’s default error response will be returned to the client.
- Return a JavaScript error and custom response by setting the `error` and `response` properties
- Return a custom or modified response by setting the `response` property
- Return nothing

Response handlers cannot return an object with the `request` property set.

## wRequest and wResponse objects

If your handler function processes requests, it will be called with a `wRequest` object.

If your handler function processes responses, it will be called with a `wRequest` and `wResponse` object.

### wRequest object

```

{
  body: {
    data: ...,
    encoding: ...,
    modified: ...,
    truncated: ...,
  },
  headers: ...,
  method: ...,
  path: ...,
  peerAddress: ...,
  query: ...,
  originRequest: {
    headers: ...,
    host: ...,
    keepaliveTimeout: ...,
    path: ...,
    port: ...,
    protocol: ...,
    readTimeout: ...,
    sslProtocols: ...,
  },
  providerSpecific: {
    ...,
  }
}
```

### wRequest object properties

Property | Description
-- | --
`body.data` | Content of the request body
`body.encoding` | Encoding of the request body. Valid values are `text` or `base64`.
`body.modified` | If your handler modifies the original request body, this property must be set to `true`
`body.truncated` | Some cloud providers place limits on the size of request bodies. If a request body is larger than this limit, they might truncate the content that is available to your handler. Valid values are `true` or `false`.
`headers` | HTTP request headers that the client sent. A header value can be retrieved by calling its `get` method with the header name. A header value can be set by calling its `set` method with the header name and value. Header names are case-insensitive.
`method` | HTTP method of the client’s request
`originRequest.headers` | HTTP request headers that will be sent to origin. A header value can be retrieved by calling its `get` method with the header name. A header value can be set by calling its `set` method with the header name and value. Header names are case-insensitive.
`originRequest.host` | Hostname used on the request sent to origin
`originRequest.keepaliveTimeout` | Maximum amount of time that the connection to origin will be kept alive (in seconds)
`originRequest.path` | Path to use when retrieving a resource from origin
`originRequest.port` | Port number on which to connect to origin
`originRequest.protocol` | Connection protocol to use when connecting to origin
`originRequest.readTimeouts` | Maximum amount of time to wait for a response from origin (in seconds)
`originRequest.sslProtocols` | Minimum SSL/TLS protocol to use when creating an HTTPS connection with origin, as an array. If multiple protocols are specified, they are tried in order.
`path` | Path from the requested URI. This property can be changed so the HTTP response returns a different resource.
`peerAddress` | IP address of the client from which the request originates
`providerSpecific` | Object containing any additional information included by your cloud provider
`query` | Query string from the requested URI

### wResponse object

```
{
  body: {},
  headers: ...,
  statusCode: ...,
  providerSpecific: {
    ...,
  }
}
```

### wResponse object properties

Property | Description
-- | --
`body` | Not all cloud providers grant access to the response body. If your cloud provider does, this property stores an object with the `data` and `encoding` properties. These properties can be updated if they exist and added if they do not. Using the `body` property, you can inspect or replace the response. The encoding of `data` must match the value of the `encoding` property.
`headers` | HTTP response headers that will be sent to the client. A header value can be retrieved by calling its `get` method with the header name. A header value can be set by calling its `set` method with the header name and value. Header names are case-insensitive.
`providerSpecific` | An object containing any additional information included by your cloud provider. The properties that are mutable depend on your cloud provider.
`statusCode` | HTTP status code sent to the client. This property can be updated and it must be specified.

## AWS property mutability

#### wRequest

  Immutable:</br>
- `peerAddress`</br>
- `method`</br>
- Properties in `providerSpecific`</br>

Mutable:</br>
- All other fields

#### wResponse

  Immutable:</br>
- Properties in `providerSpecific`</br>

Mutable:</br>
- All other fields

## Examples of handler functions

Following are some examples of handler functions.

### Request handlers

#### Generating an error when a specific request header is set

```
exports.generatesErrorHandler = (wRequest) => {
  if (wRequest.headers.get('webscale-generate-error')) {
    return {
      error: Error('Operator error'),
      response: {
        body: {
          modified: true,
          data: '<html>Generated error</html>',
          encoding: 'text',
        },
        headers.set('content-type', 'text/html'),
        statusCode: 400,
      },
    };
  }
};
```

#### Modifying the request query parameters

```
exports.addQueryHandler = (wRequest) => {
  wRequest.query = "delay=10s";
  return {
    request: wRequest,
  };
};
```

#### Adding a request header sent to origin using an asynchronous JavaScript function

```
exports.addCustomOriginHeader = async (wRequest) => {
  wRequest.originRequest.headers.set(
    'your-header-name',
    'your-header-value',
  );
  return new Promise((resolve, reject) => {
    resolve({
      request: wRequest,
    });
  });
};
```
#### Modifying the request body sent to origin using an asynchronous JavaScript function

```
exports.changeRequestBodyHandlerAsync = async (wRequest) => {
  if (wRequest.method == 'POST') {
    wRequest.headers.set('host', 'ptsv2.com');
    wRequest.originRequest.host = 'ptsv2.com';
    wRequest.originRequest.protocol = 'http';
    wRequest.originRequest.port = 80;
    wRequest.body.modified = true;
    wRequest.body.encoding = 'text';
    wRequest.body.data = 'This is a brand new POST body.';
  }
  return new Promise((resolve, reject) => {
    resolve({
      request: wRequest,
    });
  });
};
```

### Response handlers

#### Redirecting a response to another page

```
exports.redirectToWebscale = (wRequest, wResponse) => {
  wResponse.statusCode = 301;
  wResponse.headers.set(
    'location',
    'https://www.webscale.com',
  );
  return {
    response: wResponse,
  };
};
```

#### Replacing a response completely

```
exports.helloWorldResponse = (wRequest, wResponse) => {
  wResponse.body.modified = true;
  wResponse.body.data = '<html>hello world</html>';
  wResponse.body.encoding = 'text';
  wResponse.headers.set('content-type', 'text/html');
  wResponse.headers.set('content-encoding', '');
  return {
    response: wResponse,
  };
};
```

#### Hijacking the response to return an error using an asynchronous JavaScript function

```
exports.responseError = async (wRequest, wResponse) => {
  wResponse.body.modified = true;
  wResponse.body.encoding = 'text';
  wResponse.body.data = '<html>Resource not found</html>';
  wResponse.headers.set('content-type', 'text/html');
  wResponse.headers.set('content-encoding', '');
  wResponse.statusCode = 404;
  return new Promise((resolve, reject) => {
    resolve({
      error: Error('Not found'),
      response: wResponse,
    });
  });
};
```

## Testing handlers

You can write unit tests for your handler using any JavaScript testing framework. Additionally, the ``@webscale-networks/cloudedge-handlers`` node module includes a testing framework that will automatically run each handler function defined in your `manifest.json` file against a collection of tests that enforce the CloudEDGE handler interfaces and specific constraints of your cloud provider.

To run the CloudEDGE handler test suite, simply run the `run-execution-testing.js` node script. To integrate the test suite into your NPM build process, you can run the script on the `posttest` NPM event by updating the [scripts](https://docs.npmjs.com/cli/v8/using-npm/scripts) section of your `package.json` file.

{{% alert title="Note:" %}}
NPM versions 8.0.0 and higher require a `test` event as well. If you do not have tests of your own, input an empty string.
{{% /alert %}}

#### Integrating the CloudEDGE handler testing framework

```
“scripts”: {
  ...
  “posttest“:
    "node node_modules/@webscale-networks/cloudedge-handlers/run-execution-testing.js <cloud-provider>",
  ...
}
```

``<cloud-provider>`` should be replaced with the name of the cloud provider for the test. For AWS providers, use `aws`.

To execute NPM’s testing pipeline, run `npm test` in the root directory of your package.

To create mock `wRequest` and `wResponse` objects in your own unit tests, import the following mock data available to you from the CloudEDGE handler test suite.

- Complete `wRequest` and `wResponse` objects are available in: ``.../node_modules/@webscale-networks/cloudedge-handlers/execution_testing/webscale/src/object.js``
- The case-insensitive HTTP header class is available in: ``.../node_modules/@webscale-networks/cloudedge-handlers/execution_testing/utils/src/headers.js``

## Further reading

- [CloudEDGE Workers Overview](/docs/how-tos/CloudEDGE/workers-overview/)
- [CloudEDGE Workers Usage Example](/docs/how-tos/CloudEDGE/workers-usage-example/)
---
# Egress Proxy How-To Guides
URL: https://docs.webscale.com/docs/how-tos/egress-proxy/
Description: Guides to using the Webscale egress proxy.



The egress proxy is an optional component within the hosting environment designed to route outbound HTTP and HTTPS traffic through a fixed, static IP address. Structurally, this proxy is deployed on the NFS server and is configured for specific hostnames via the web server cluster metadata settings.
---
# Creating Web Controls
URL: https://docs.webscale.com/docs/how-tos/web-controls/webcontrols_create/
Description: Create Web Controls through the Webscale Control Panel



{{% include webcontrol.md %}}

You can also create sequences of these rules that can accomplish much more complex behavior, such as dynamic allowlisting or rate limiting checkout attempts based on user behavior.


You can create request and response Web Controls which apply rules respectively to requests or responses. Except for accessing the request and response Web Controls pages, the process for creating both are the same. While the request and response Web Controls share many conditions and actions, the available conditions and actions are not the same.

## Access the Request web controls page

### To access the Request web controls page

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select **Edit**.

   {{< figure src="/images/access_edit_app_box.png" alt="Select Edit from application box" >}}

   -or-

   On your application page, click the **Actions** menu icon and select **Edit**.

   {{< figure src="/images/access_edit_action_menu.png" align="left" width="50%" alt="Select Edit from Action menu" >}}

2. On the sidebar menu, select **Request web controls**. The **Request web controls** page displays.

    {{< figure src="/images/web_controls/select_request_web_controls_sidebar.png" alt="Select Request web controls on sidebar menu" >}}

## Access the Response web controls page

#### To access the Response web controls pages

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select **Edit**.

   {{< figure src="/images/access_edit_app_box.png" alt="Select Edit from application box" >}}

   -or-

   On your application page, click the **Actions** menu icon and select **Edit**.

   {{< figure src="/images/access_edit_action_menu.png" align="left" width="50%" alt="Select Edit from Action menu" >}}

2. On the sidebar menu, select **Response web controls**. The **Response web controls** page displays.

    {{< figure src="/images/web_controls/select_response_web_controls_sidebar.png" alt="Select Web Controls on sidebar menu" >}}

## Create Web Controls

You do not have to create any conditions for a request or response Web Control. If you do not create any conditions, Webscale will apply all actions to every request or response. If you have one or more conditions, the requests and responses must meet all of the conditions before the actions will execute.

You must create at least one action for a Web Control. If you have more than one action, all of them run for each request or response that meets all of the conditions. For the other actions, the order in which they run is unspecified and not necessarily in the order displayed in the list of actions for the Web Control.

#### To create a Web Control

1. On the **Request web controls** page, click **Add a request web control**.</br>

    {{< figure src="/images/web_controls/click_add_request_web_control.png" alt="Edit request web controls section" >}}

    The sections for configuring request Web Controls display under the **Edit request web control** heading.

    {{< figure src="/images/web_controls/request_web_controls_section.png" alt="Edit request web controls section" >}}

    -or-</b>

    On the **Response web controls** page, click **Add a response web control**.</br>

    {{< figure src="/images/web_controls/click_add_response_web_control.png" alt="Click Add a response web control" >}}

    The sections for configuring response Web Controls display under the **Edit response web control** heading.

    {{< figure src="/images/web_controls/response_web_controls_section.png" alt="Edit request web controls section" >}}

2. Enter a name and optional description for the Web Control.
3. To add a condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.</br>
    b. In the condition drop-down menu, select a condition.</br>
    c. Specify the condition settings.</br>
    d. Click **Done**.</br>

4. To add other conditions, repeat the above procedure for adding a condition, choosing different conditions and entering the settings for each new condition.
5. To add an action:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add action**.</br>
    b. In the **Type** drop-down menu of the **Create action** section, select an action.</br>
    c. Specify the action settings.</br>
    d. Click **Done**.</br>
6. Click **Done**.
7. To add other conditions, repeat the above procedure for adding an action, choosing different actions and entering the settings for each new actions.
8. On the right side of the **Edit request web control** header, click **Done**.
9. Click **Apply**.

## Further Reading

- [How To Shield Your Online Storefront From Cyberthreats With Webscale's Web Controls](https://www.webscale.com/blog/shield-online-storefront-cyberthreats-webscale-web-controls/)
- [What are Web Controls, and how do I use them?](/docs/faq/#what-are-web-controls-and-how-do-i-use-them/)
- [Configuring Web Controls for Rate Limiting](/docs/how-tos/advanced/rate-limiting/)
- [How to Block Countries](/docs/how-tos/security/block-countries/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Managing Web Controls
URL: https://docs.webscale.com/docs/how-tos/web-controls/webcontrols_manage/
Description: Manage Web Controls through the Webscale Control Panel



{{% include webcontrol.md %}}

You can also create sequences of these rules that can accomplish much more complex behavior, such as dynamic allowlisting or rate limiting checkout attempts based on user behavior.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}
## Manage Web Controls

Click **Web Controls** on the menu.

{{< figure src="/images/web_controls/manage_main.png" alt="Webscale Web Controls page in the control panel" >}}

Here you manage or create Web Controls. You can also change or lock the execution order of the Web Controls, enable or disable specific Web Controls, refresh the hits counter, and edit or delete Web Controls.

- To create a new Web Control, click the **Add A Web Control** button. Read more: [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).
- To set the order of the Web Controls, click the <i class="fa fa-ellipsis-v" aria-hidden="true"></i> 3 vertical dots next to **Web Controls** at the top of the Web Controls list, and choose **Unlock order** from the list. Then, click on the Web Control you wish to move in the list.
- To lock the order of the Web Controls, click the <i class="fa fa-ellipsis-v" aria-hidden="true"></i> 3 vertical dots next to **Web Controls** at the top of the Web Controls list, and choose **Lock order** from the list.
- To enable or disable a Web Control, click the checkbox labeled **Enabled** next to the Web Control you wish to modify.
- To view details of a Web control, click the arrow `>` next to it. You can also click the **Expand all** checkbox to view the details of all Web Controls.
- To edit or delete a Web Control once you've expanded it, click the `X` icon to delete or the pencil box icon to edit the Web Control.
- To refresh the hits counter, click the refresh icon. This action resets the counter to 0, so be careful!

{{% alert title="Note:" %}}
The hits counter keeps track of how many times each Web Control has run in the last 5 minutes.
{{% /alert %}}

## Further Reading

- [How To Shield Your Online Storefront From Cyberthreats With Webscale's Web Controls](https://www.webscale.com/blog/shield-online-storefront-cyberthreats-webscale-web-controls/)
- [What are Web Controls, and how do I use them?](/docs/faq/#what-are-web-controls-and-how-do-i-use-them/)
- [Configuring Web Controls for Rate Limiting](/docs/how-tos/advanced/rate-limiting/)
- [How to Block Countries](/docs/how-tos/security/block-countries/)
- [Security How-Tos](/docs/how-tos/security/)
---
# Using URL Maps to Redirect URLs
URL: https://docs.webscale.com/docs/how-tos/web-controls/url-maps/
Description: Use URL maps to redirect URLs through the Webscale Control Panel




The URL mapping feature enables you to redirect requests from one URL (*from*) to another URL (*to*). A comma-separated values (CSV) file specifies the from and to URLs. If desired, you can bulk import  matching pairs of URLs.

One example of when you might use URL mapping is when you revise your website. This can lead to orphaned URLs. When site visitors use an orphaned URL, a web page with a `404` error code displays rather than a viewable page. A URL map enables you to avoid this potential problem.

Or, another reason to use this feature might be to redirect from one viewable web page to another one.

{{% alert title="Note:" %}}
URL maps are available to all applications for your account. Different applications can use the same URL map.
{{% /alert %}}


## URL mapping

Each URL map incorporates a URL map file that specifies the *from* and *to* URLs. Web Controls redirect requests in conjunction with URL maps. When the URL of a request matches a *from* URL, the Web Control sends it to the web page with the *to* URL. Through Web Controls, you can configure  additional mapping criteria.

The **URL maps** tab enable you to create, edit, and delete URL maps.

{{< figure src="/images/url_maps/url_maps_tab.png" alt="URL maps tab" >}}

## URL map files

A URL map file is a CSV file that specifies *from* and *to* pairs of URLs. The file should have two values on each line, separated by a comma to ensure that your URL map successfully redirects orphaned URLs. See the following example of a line for a URL map file.

`http://www.example.com/<old_page> , http://www.example.com/<new_page>`

After you are done adding URLs to the file, save it with the `.csv` file extension.

## Create URL Maps

When you create a URL map, enter a name and upload the URL map file. Optionally, you can add a description.

Webscale parses the map file data before it creates the URL map. If the map file data is formatted incorrectly or invalid, you cannot create the URL map.

### To create a URL map

1. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on the upper left of the screen.
2. Select **URL maps** on the sidebar menu.

    {{< figure src="/images/url_maps/select_url_maps.png" alt="Select URL maps sidebar menu entry" >}}

3. On the **URL maps** tab, click **Create URL map**.
4. Enter a URL name and, optionally, a description.
5. Click **Choose File** to upload a URL map file.
6. Select a file on your computer and click **Open**.
7. Click **Save**.</br>
    The URL map information displays on the **URL maps** tab.

    {{< figure src="/images/url_maps/create-url-map.png" alt="Create URL map" >}}

## Edit URL maps

When you edit a URL map, you can perform the following operations.

- Hide details
- Edit name and description
- Upload map file
- Download map file
- Delete map

When you select a URL map, detailed information displays for it in the **Details** section. Through the edit menu, you can hide the details or view them again if they are hidden. (You can also show hidden details by selecting the URL map.)

You can also replace a URL map file by uploading a different one or downloading the existing map file.

{{< figure src="/images/url_maps/url_maps_edit_menu.png" alt="URL maps edit menu" >}}

### To edit a URL map

1. On the **URL maps** tab, select the URL map that you want to edit.
2. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> to the right of the **Updated** column. The edit menu displays.
2. On the edit menu:
    - Hide the URL map details by selecting **Hide details**. To view hidden details, select **View details**.
    - Edit the map name and description by selecting **Edit name and description**.
    - Replace the map file with a new one by selecting **Download map file** and uploading a new file.
3. For each editing operation, except for hiding and viewing details, click **Apply** to save the changes.

## Delete URL Maps

You can also use the edit menu to delete URL maps.

### To delete a URL maps

1. On the **URL maps** tab, select the URL map that you want to delete.
2. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> to the right of the **Updated** column. The edit menu displays.
3. On the edit menu, select **Delete map**.
4. In the confirmation  box, click **Ok**.

## Web Controls

Web Controls consist of configured rule sets that minimize the need to define and maintain multiple individual rules. Instead, you can create rule sets that match individual request conditions.

Based on the conditions, Web Controls automatically execute a set of pre-defined actions. Web Controls also enable you to create complex sequences of actions. When one or more specified conditions are met, Webscale applies all configured actions to the request.

For URL mapping, optional conditions can specify when Webscale redirects URLs. The **Redirect using map** action is mandatory and enables the Web Control to re-direct URLs. When you select this action type, you must select a HTTP status code, URL map, and if Webscale will preserve request or query parameters for the request or *from* URL.

### Settings for the Redirect using map action

When you select the **Redirect using map** action type, you must configure the following settings.

- HTTP status
- URL map
- Preserve query

The **HTTP status** setting defines the HTTP status code that all redirected requests for the URL map return.

The **URL map** setting specifies the URL map that the Web Control will use.

If the query preserving feature is enabled through the **Preserve query** toggle, the final redirected URLs (otherwise known as the output URLs) will include request query parameters for each pair in the map. Query parameters follow the differing paths for the *from* and *to* URLs.

If disabled, Webscale discards the request query parameter.

### URL mapping and query parameters

The following table illustrates how URL mapping works when the **Preserve query**  setting is enabled and disabled.

Request URL	| URL map <em>from</em> | URL map <em>to</em>	| Preserve query parameter |  Output URL
-- | -- | -- | :--: | -- |
example.com/ex?a=b | example.com/ex	| example.com/ab?y=z | True | example.com/ab?y=z |
example.com/ex?a=b | example.com/ex	| example.com/ab | True | example.com/ab?a=b |
example.com/ex?a=b | example.com/ex?a=b | example.com/ab?y=z | True | example.com/ab?y=z
example.com/ex?a=b | example.com/ex?a=b | example.com/ab | True | example.com/ab
example.com/ex?a=b | example.com/ex | example.com/ab?y=z | False | example.com/ab?y=z
example.com/ex?a=b | example.com/ex | example.com/ab | False | example.com/ab
example.com/ex?a=b | example.com/ex?a=b | example.com/ab?y=z | False | example.com/ab?y=z
example.com/ex?a=b | example.com/ex?a=b | example.com/ab | False | example.com/ab

## Create Web Controls to redirect URLs

The **Web controls** page enables you to create Web Controls. For more information on creating Web Controls, see [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).

### To create a Web Control to redirect URLs

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper right corner of the application box and select **Edit**.

   {{< figure src="/images/access_edit_app_box.png" alt="Select Edit from application box" >}}

   -or-

   On your application page, click the **Actions** menu icon and select **Edit**.

   {{< figure src="/images/access_edit_action_menu.png" alt="Select Edit from Action menu" >}}

2. On the sidebar menu, select **Web Controls**. The **Web controls** page displays.

    {{< figure src="/images/web_controls/select_web_controls_sidebar.png" alt="Select Web Controls on sidebar menu" >}}

3. On the **Web controls** page, click **Add a web control**.</br>
    The sections for configuring Web Controls display under the **Edit web control** heading.
4. Enter a name and optional description for the Web Control.

   {{< figure src="/images/url_maps/url-maps-edit-web-controls-section.png" alt="Enter Web Controls name and description" >}}

5. Optionally, to add a condition:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add a condition**.</br>
    b. In the condition drop-down menu, select a condition and define the settings for the condition.</br>
    You can select additional conditions.</br>
    c. Click **Done**.
6. To add the **redirect select_url_maps** action:</br>
    a. Click <i class="fa fa-plus-circle" aria-hidden="true"></i> **Add action**.</br>
    b. In the **Type** drop-down menu, select **Redirect using map** under **Final actions**.</br>
        The **Create action** section displays.</br>
    c. In the **HTTP status code** drop-down menu, specify a status code for responses to the *from* URLs in the URL map.</br>
    d. Select a URL map in the **URL map** drop-down menu.</br>
    e. Click the **Preserve query** toggle to enable or disable preserving queries in the mapping.</br>
    f. Click **Done**.</br>
        You can select additional actions.

   {{< figure src="/images/url_maps/url-maps-action-settings.png" alt="Redirect using map action settings" >}}

7. To the right of the **Edit web control** header, click **Done**.
8. Click **Apply**.

## Further Reading

- [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
- [Managing Web Controls](/docs/how-tos/web-controls/webcontrols_manage/)
- [List of HTTP status codes](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
---
# How to Set Pagespeed Options
URL: https://docs.webscale.com/docs/how-tos/web-controls/pagespeed/
Description: A brief walkthrough on setting Pagespeed options in Web Controls



{{% include webcontrol.md %}} A typical action to define is to set Pagespeed Options.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

{{% alert color="info" title="Prerequisite" %}}
Since you’re setting a Web Control, we recommend reading [How to Create Web Controls](/docs/how-tos/web-controls/webcontrols_create/) before following these steps.
{{% /alert %}}
Click **+ Add Action** to open the **Create Action** dialog. Click the **Select an action..** dropdown to open it and choose **Set Pagespeed Options** from the list.

{{< figure src="/images/web_controls/create_action_pagespeed.png" alt="Webscale Create Action dialog in the control panel showing Set Pagespeed Options" >}}

Choose **Yes** if you want this action to run the Pagespeed options specified below, **No** to not run the options, or **Make no decision** for the Web Control to make no changes to existing behavior.

In the text area labeled **Select the filters to enable when Pagespeed runs**, choose from the list of Pagespeed options for this action to run. When finished, click the **Done** button to return to the Edit Web Control screen. You can add more than one action. Note that all actions specified are run, but there is no implied order.

When a condition is met, then all specified actions are applied to the request. You can only choose one final action. Final actions run last; the order of execution of other actions is unspecified and not necessarily in the order displayed.

## Further Reading
- [Pagespeed Options](/docs/reference/pagespeed_options/)
- [How To Shield Your Online Storefront From Cyberthreats With Webscale's Web Controls](https://www.webscale.com/blog/shield-online-storefront-cyberthreats-webscale-web-controls/)
- [What are Web Controls, and how do I use them?](/docs/faq/#what-are-web-controls-and-how-do-i-use-them/)
- [How to Block Countries](/docs/how-tos/security/block-countries/)
---
# Enforcing a Content Security Policy
URL: https://docs.webscale.com/docs/how-tos/web-controls/csp-create/
Description: A brief walkthrough on setting Content Security Policy options in Web Controls



{{% include webcontrol.md %}}

A powerful Web Control action you can use is the **Content Security Policy** action.

{{% alert title="Note:" %}}
This is an optional feature. If you'd like to enable this feature, please [contact support](mailto:support@webscalenetworks.com).
{{% /alert %}}

## Configure a Content Security Policy

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

{{% alert color="info" title="Prerequisite" %}}
Since you’re setting a Web Control, we recommend reading [How to Create Web Controls](/docs/how-tos/web-controls/webcontrols_create/) before following these steps.
{{% /alert %}}

Click **+ Add Action** to open the **Create Action** dialog. Click the **Select an action..** dropdown to open it and choose **Content Security Policy** from the list. Then, click **Add Directive..** to see the list of available [Content Security Policy](/docs/reference/content-security-policy/) directives, and choose one from the list.

{{< figure src="/images/web_controls/create_action_csp.png" alt="Webscale Create Action dialog in the control panel showing Content Security Policy" >}}

{{% alert title="Note:" %}}
When you click the **Enable** toggle to enable the **Report only** setting, the `Content-Security-Policy` header will be replaced with a `Content-Security-Policy-Report-Only` header.
{{% /alert %}}

Depending on the directive chosen, you may have to add the specific [source](/docs/reference/content-security-policy/#source) or [value](/docs/reference/content-security-policy/#sandbox-values) that applies to the directive. When finished, click the **Done** button to return to the Edit Web Control screen. You can add more than one action. Note that all actions specified are run, but there is no implied order.

When a condition is met, then all specified actions are applied to the request. You can only choose one final action. Final actions run last; the order of execution of other actions is unspecified and not necessarily in the order displayed.

See [Content Security Policy Directives](/docs/reference/content-security-policy/) for a list of directives and sources you can choose from.

## Content Security Policy Logs

When a content security policy is violated, a log entry is created that contains information about the violation.

### Violation report parameters

| Parameter | Explanation |
|---------|----------|
| `arrival` | Timestamp of when the report was received by the Webscale proxy |
| `blocked_uri` | URI of the resource that was blocked from loading by the Content Security Policy. If the blocked URI is from a different origin than the `document-uri`, then the blocked URI is truncated to contain just the scheme, host, and port. |
| `country` | Two-letter country code (ISO 3166-1) for the origin of a request |
| `disposition` | “enforce” if the Content-Security-Policy response header was used. “report” if the Content-Security-Policy-Report-Only response header was used. |
| `document_uri` | URI of the document in which the violation occurred |
| `effective_directive` | Directive the enforcement of which caused the violation |
| `host` | URL of the application that was requested |
| `original_policy` | Original policy as specified by the Content-Security-Policy response header |
| `peer_address` | IP address of the proxy that received the report |
| `referrer` | Referrer of the document in which the violation occurred |
| `request_address` | Remote IP address of the user agent that made the request |
| `script_sample` | First 40 characters of the inline script, event handler, or style that caused the violation |
| `session_id` | ID of the Webscale session that attempted to load the resource |
| `status_code` | Response status code that indicates the response to a specific request |
| `useragent` | User agent used in the request |
| `violated_directive` | Name of the violated policy section |

More information about the violation report syntax can be found on the [Firefox MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#Violation_report_syntax).

### Viewing the Content Security Policy logs

{{% alert %}}
{{% include dashboard-login.md %}}

On the menu that appears, click **CSP reports** to view the content security policy logs.
{{% /alert %}}

On the Traffic Viewer page for CSP reports, you can use filter queries to drill down through the reports. The  filter uses CSP report attributes, which are the same as the [violation parameters](#violation-report-parameters). For more information on CSP report attributes, including aliases that you can use in filters, see [CSP Report Logs](/docs/how-tos/traffic-viewer/csp-reports-attributes/)


For example, the following filter query will show you all instances of `blocked_uri` that contain the string `admin`:
```
blocked_uri ~ *admin*
```
The filter accepts wildcard characters (`*`).

### Alerting on Content Security Policy violations

You can monitor the Content Security Policy logs and configure a monitor to notify you if a specific Content Security Policy you've set is violated.

When logged into the Webscale Control Panel, click the <i class="fas fa-cog" aria-hidden="true"></i> (gear) icon on the upper right, and select **Account Settings** from the menu. Then click the **Monitors** tab, which takes you to the [Monitors page.](https://control.webscale.com/account/monitors) Click the **Create monitor** button to display the following:

{{< figure src="/images/web_controls/create-monitor.png" alt="Create monitor box in the Webscale Control Panel" >}}

Choose the following options:

- **Type**: Choose `logs`.
- **Name**: A name to identify the monitor with.
- **Description**: A short description of the monitor or it's purpose.
- **Add Label**: Click here to add an existing label that is already applied to a related system resource.
- **Message**: The message sent in the notification. This field accepts [liquid templates](https://shopify.github.io/liquid/) that render to markdown. This markdown is then rendered to HTML in the message sent. The templates differ depending on the monitor context (specified by the label) chosen.
- **Notify**: Where to send the notification. This field currently only accepts email addresses, but Webhooks are coming soon.

{{% alert %}}
The following items show once you choose `logs` from the first **Type** field.
{{% /alert %}}

- **Log Type**: Choose `csp-reports` here.
- **Duration**: Set a duration over which to monitor violations, in seconds.
- **Group By**: Divides the violations into groups on values of the attribute chosen here. Webscale then evaluates the condition for each group to determine if there are any groups that should cause a notification.
- **Condition**: Choose the condition, which must be in `outlier(<int>, <float>)` form.
- **Filter**: Similar to the [Traffic Viewer's filter](/docs/how-tos/traffic-viewer/filter-traffic-viewer/), but the parameters can only be [Content Security Policy violation parameters](#violation-report-parameters).

Once configured, you will receive notifications for Content Security Policy log entries that match the above settings.

## Further Reading
- [Content Security Policy (Firefox MDN web docs)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [Content Security Policy Directives](/docs/reference/content-security-policy/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
---
# Using Image Manager
URL: https://docs.webscale.com/docs/how-tos/web-controls/image-manager/
Description: Configure Image Manager through the Webscale Control Panel




The Webscale {{< term "image_manager" >}} product is an image processing service that uses a JavaScript library called Sharp to automatically manipulate images. The library filters change image compression, size, and format according to your specifications.

{{< term "image_manager" >}} offers a one-stop, automated image optimization and management solution to dynamically optimize delivery, significantly improve page load times, and reduce spending. Improvement in the size and bandwidth usage of delivered images can result in higher Core Web Vitals scores. The main objective of {{< term "image_manager" >}} is to replace web page images with smaller optimized versions for better website performance.

After Webscale support deploys {{< term "image_manager" >}}, it runs automatically, using default request Web Controls and cache settings. You can change these settings so that {{< term "image_manager" >}} processes images differently. For example, you might want users to be able to view the details of site images better. You can raise image quality by decreasing compression, which increases file size and resolution, through a Web Control filter setting. However, larger files lead to slower page load times.

Through Web Controls, you can ensure the ongoing high performance, availability, and security of your websites through customized conditions and actions that Webscale applies to your website traffic. Web Controls consist of configured rule sets that minimize the need to define and maintain multiple individual rules. Instead, you can create rule sets that match individual request and response conditions. When a request meets specified conditions, Web Controls execute a set of pre-defined actions. Web Controls enable you to create complex sequences of actions that run automatically.

{{% alert title="IMPORTANT:" %}}
We strongly recommend that the only Web Controls settings that you modify are the ones for the image processing filters. All other conditions and actions are configured correctly for {{< term "image_manager" >}}. Do not add new conditions and actions for the Web Controls.
{{% /alert %}}

## Topics

- [Overview](#overview)
- [AWS Lambda](#aws-lambda)
- [Default Web Controls](#default-web-controls)
     - [Conditions](#conditions)
     - [Actions](#actions)
     - [Filters](#filters)
- [Cache processed images](#cache-processed-images)
    - [CDN caching policies](#cdn-caching-policies)
    - [Site cache settings](#site-cache-settings)
- [Change image processing settings](#change-image-processing-settings)
- [Filters overview](#filters-overview)
    - [Supported filters](#supported-filters)

## Overview

A browser generates a request for an image. If the request meets all of the conditions for a Web Control for {{< term "image_manager" >}}, the following process takes place.

1. The **Use alternate backends** action for an {{< term "image_manager" >}} Web Control calls the AWS API Gateway endpoint and specifies the filters and their settings. </br>
     -and-</br>
     **Set request header** and **Set response header** actions modify the request and response headers to give configuration values to {{< term "image_manager" >}}. They also provide information about if {{< term "image_manager" >}} processed the request and the Web Control for it.
2. The AWS API Gateway triggers the AWS Lambda service, which makes the Lambda run.
3. {{< term "image_manager" >}} makes a request inside the Lambda to get the original image from your backend application or Site Cache, depending on which one contains the image.
4. Webscale serves the image from the appropriate cache.
5. Through the Sharp JavaScript library, {{< term "image_manager" >}} applies the filters to the image.
6. Webscale caches the processed image and sends it to the web browser that created the request.

You can change how {{< term "image_manager" >}} processes images by modifying the **Use alternate backends** action, which specifies the image filters and their settings.

You might need a new Web Control to meet your organization's needs. For example, you might want {{< term "image_manager" >}} to process banner images and apply specific optimization settings. Or, you might deploy {{< term "image_manager" >}} on a locked-down staging site that only allows access based on specific IP addresses for testing. An additional Web Control could enable {{< term "image_manager" >}} Lambdas to access your backend application.

To add a Web Control for {{< term "image_manager" >}}, contact [support](mailto:support@webscalenetworks.com).

{{% alert title="Note:" %}}
The {{< term "image_manager" >}} installation process automatically creates three default request Web Controls. They are crucial for {{< term "image_manager" >}} to run. Do not delete them. For more information on the Web Controls, see [Default Web Controls](#default-web-controls).
{{% /alert %}}

## AWS Lambda

AWS Lambda is a serverless, event-driven service. It enables Webscale to run code for virtually any type of application or backend service.

Lambdas are simple functions that you can invoke to run your code. Each Lambda is used just once. It has code to process the events that you pass into the function or that other AWS services send to the function. For more information on AWS Lambda, see the AWS documentation for [What Is AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html).

A trigger is a resource or configuration that invokes an AWS Lambda function. Triggers include AWS services that you can configure to invoke a function.

## Default Web Controls

{{< figure src="/images/web_controls/image-manager/image_manager_expanded_desktop_web_control.png" align="left" width="100%" alt="Image Manager desktop Web Control with condition and actions sections called out" >}}

Webscale automatically creates three request Web Controls during {{< term "image_manager" >}} installation. These standard Web Controls have default conditions, actions, and filters with specific settings. Their names correspond to each of the following user types.

- Webscale Image-Manager Mobile: Mobile users
- Webscale Image-Manager: Desktop users with other browsers or newer versions of the Safari browser (2014 and higher)
- Webscale Image-Manager Safari: Desktop users with a version of the Safari browser that does not support WebP-formatted images (2013 and older)

    {{< figure src="/images/web_controls/image-manager/image_manager_web_controls_list.png" align="left" width="100%" alt="List of Image Manager Web Controls" >}}

The three standard Web Controls cover the different image processing needs for each type of user. For instance, small images render faster on mobile device screens and decrease data transfer while larger ones can display better for desktop users.

For requests that meet the conditions for the Webscale Image-Manager Mobile and Webscale Image-Manager Web Controls, {{< term "image_manager" >}} converts all images to the WebP (WebP) file format.

However, not all versions of the Safari browser support WebP-formatted images. The Webscale Image-Manager Safari Web Control pertains to requests from versions of the Safari browser that do not support WebP-formatted images.

For requests that meet the conditions for the  Webscale Image-Manager Safari Web Control, {{< term "image_manager" >}} does not convert the images to the WebP file format. All images retain their file formats unless the requests are for JPEG (JPEG) or Portable Network Graphics (PNG) images. Then, {{< term "image_manager" >}} converts them to progressive JPEG or PNG images. For more information on the Progressive and other default filters, see [Filters](#filters).

{{% alert title="Note:" %}}
In the **Request web controls** page, the default Web Controls are grouped together and list in the order presented in the above screenshot. Keep them grouped in this order.
{{% /alert %}}

{{% alert title="Note:" %}}
If there are CORS, blocking, PageSpeed, or general Web Controls, move the {{< term "image_manager" >}} Web Controls below them in the list of Web Controls if they are not already.
{{% /alert %}}

### Conditions

The following table presents the default conditions for the standard Web Controls. For more information on conditions, see [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).

{{< figure src="/images/web_controls/image-manager/image_manager_mobile_conditions.png" align="left" width="50%" alt="Image Manager Mobile Web Control conditions" >}}

{{< figure src="/images/web_controls/image-manager/image_manager_desktop_conditions.png" align="left" width="50%" alt="Image Manager Web Control desktop conditions" >}}

{{< figure src="/images/web_controls/image-manager/image_manager_safari_conditions.png" align="left" width="50%" alt="Image Manager Safari Web Control conditions" >}}

**Type** | **Setting details** | **Webscale Image-Manager Mobile** | **Webscale Image-Manager** | **Webscale Image-Manager Safari**
-- | -- | -- | --| -- |
Request header value does not match | Actions will be applied when the header `Image-Retrieved` does not match the pattern of `true` | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |
User agent matches | Actions will be applied when the user-agent in the request matches one of the following patterns: `.*iPhone.*`, `.*iPod.*`, `.*Android.*` | <p class="tabyes">Yes</p> |  |  |
URL matches | `*.jpg`, `*.jpeg`, `*.png`, `*.webp` as supported paths | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |
URL does not match |  `/*` as the path and `image-handler=off` as the query | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |
Request headers match | `webp-accepted` as the name and `true` as the pattern |  | <p class="tabyes">Yes</p> |  |
Request headers match | `webp-accepted` as the name and `false` as the pattern |  |  | <p class="tabyes">Yes</p> |

### Actions

The following table presents the default actions for the standard Web Controls. For more information on actions, see [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).

{{< figure src="/images/web_controls/image-manager/image_manager_mobile_actions.png" align="left" width="50%" alt="Image Manager Mobile Web Control actions" >}}

{{< figure src="/images/web_controls/image-manager/image_manager_desktop_actions.png" align="left" width="50%" alt="Image Manager desktop Web Control actions" >}}

{{< figure src="/images/web_controls/image-manager/image_manager_safari_actions.png" align="left" width="50%" alt="Image Manager desktop Web Control actions" >}}

**Type** | **Setting detail** | **Webscale Image-Manager Mobile** | **Webscale Image-Manager** | **Webscale Image-Manager Safari**
-- | -- | -- | --| -- |
Set request header | Request header will be set to: `Image-Domain: origin-<`*`your application ID`*`>.cloudmaestro.com` | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |
Set request header | Request header will be set to: `Image-Host: <`*`your default application hostname`*`>`| <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |
Set response header | Response header will be set to: `X-Webscale-ImageManager-Processed: true` | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |
Set response header | Response header will be set to: `X-Webscale-ImageManager-< `*`Mobile`*`, `*`Desktop`*`,  `*`Safari`*`>`: `true` | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p>| <p class="tabyes">Yes</p> |
Use alternate backends | Route request to servers at `<`*`your AWS API Gateway endpoint`*`>` with the remote URL `<`*`the domain for your AWS API Gateway endpoint`*`>`/image/filters: `<`*`filter name and settings`*`>` followed by `<`*`filter name and settings`*`>` for any subsequent filter with a backslash after the last filter | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> | <p class="tabyes">Yes</p> |

### Filters

Each standard Web Control includes multiple default filters, which are presented as part of the string for the remote URL of the **Use alternate backends** action.

Information for the default filters for {{< term "image_manager" >}} follows. Each entry includes the filter name, usage in parentheses, and a description.

- Format (format): Specifies reformatting images to the supported WebP, JPEG, Graphics Interchange Format (GIF), or PNG file formats
- No upscale (noupscale): Specifies that {{< term "image_manager" >}} will only resize images to a smaller size than the original and not enlargen them while using upscaling to maintain quality
- Progressive (progressive): Specifies reformatting images to progressive JPEG and PNG file formats. Progressive images load immediately at a low resolution that progressively increases.
- Quality (quality): Specifies the image quality level (on a scale of one to 100) that corresponds to the amount of compression for JPEG images. For the best quality images, which are uncompressed, the level is "100" whereas the level is "1" for minimum quality and maximum compression. For quality levels of "80" to "85," images usually decrease by 30 to 40 percent with little noticeable decrease in quality.
- Resize (fit-in): Specifies resizing images to defined dimensions.

{{% alert title="Note:" %}}
Image sizes are in pixels.
{{% /alert %}}

The following table presents the default filters and their values. For more information on {{< term "image_manager" >}} filters and syntax, see [Filters overview](#filters-overview).

{{< figure src="/images/web_controls/image-manager/image_manager_mobile_default_filters.png" align="left" width="50%" alt="Image Manager Mobile Web Control filters" >}}

{{< figure src="/images/web_controls/image-manager/image_manager_desktop_default_filters.png" align="left" width="50%" alt="Image Manager desktop Web Control default filters" >}}

{{< figure src="/images/web_controls/image-manager/image_manager_safari_default_filters.png" align="left" width="50%" alt="Image Manager Mobile Web Control default filters" >}}

**Filters** | **Webscale Image-Manager Mobile** | **Webscale Image-Manager** | **Webscale Image-Manager Safari**
-- | -- | -- | --|
``/filters:quality(60)/filters:progressive()/filters:format(webp)/fit-in/500x500/filters:noupscale()/`` | <p class="tabyes">Yes</p> |  |
``/filters:quality(60)/filters:progressive()/filters:format(webp)/fit-in/1000x1000/filters:noupscale()/`` |  |<p class="tabyes">Yes</p> |  |
``/filters:quality(60)/filters:progressive()/fit-in/1000x1000/filters:noupscale()/`` |  |  | <p class="tabyes">Yes</p> |

## Cache processed images

After Image Manages retrieves the images from your backend application and processes them, Webscale caches them. If Webscale CDN is enabled, a CDN control determines the CDN cache location for the processed images. If not, Site Cache settings specify the cache location.

Webscale support configures caching for {{< term "image_manager" >}} images as part of deployment if you do not already have a CDN control and Site Cache rule with this location.

{{% alert title="Note:" %}}
Instead of the backend application, Site Cache might contain the original image. If so, Site Cache will serve it.
{{% /alert %}}

### CDN caching policies

If Webscale CDN is enabled, Webscale support creates a CDN control for caching JPEG, PNG, and WebP images with <em>/media/*</em> as the path if the CDN control does not already exist.

For more information on caching policies and working with CDN controls, see [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/).

### Site cache settings

For your application servers, configuring {{< term "image_manager" >}} includes creating a Site Cache rule that defines caching for media images and prevents caching the origin request that retrieves the image from your backend application.

For the rule, Webscale support adds the following conditions in the **Create conditions** dialog box part of deploying {{< term "image_manager" >}}.

- For the **URL matches** condition, <em>/media/*</em> is the path for caching JPEG, PNG, and WebP images in the <strong>Path</strong> field
- For the **Request headers do not match** condition, **Image-Retrieved** is the header with **true** as the pattern

Ensure that the **Browser**, **Hostname**, and **Query** cache key properties are enabled.

For more information on creating Site Cache rules, see [Configuring and Flushing the Site Cache](/docs/how-tos/advanced/site-cache/).

## Change image processing settings

After Webscale installs {{< term "image_manager" >}}, you can change how it processes images by editing the Web Controls and modifying their filters and settings. For more information on filters, see [Filters](#filters).

#### To edit filters for a Web Control

1. Access the **Request web controls** page, according to [Access the Request web controls page](/docs/how-tos/web-controls/webcontrols_create/) in [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/).
2. In the list of Web Controls on the **Request web controls** page, click the <i class="fas fa-angle-right" aria-hidden="true"></i> symbol for the Web Control to edit.</br>

    {{< figure src="/images/web_controls/image-manager/image_manager_click_open_web_control.png" align="left" width="100%" alt="Click to access Web Control settings" >}}

    The conditions and actions for the Web Control display.
3. To the right of the conditions and actions, click the **Edit** icon <i class="fas fa-edit" aria-hidden="true"></i> for the Web Control.

    {{< figure src="/images/web_controls/image-manager/image_manager_click_edit_web_control.png" align="left" width="100%" alt="Click Edit icon for the Web Control" >}}

4. In the **Actions** section, click the the **Edit** icon <i class="fas fa-edit" aria-hidden="true"></i> for the **Use alternate backends** action.

    {{< figure src="/images/web_controls/image-manager/image_manager_click_edit_use_alternate_backends.png" align="left" width="100%" alt="Click Edit icon for the Use alternate backends action" >}}

5. Click the **Show URL mapping** link.</br>

    {{< figure src="/images/web_controls/image-manager/image_manager_click_show_url_mapping.png" align="left" width="90%" alt="Click Show URL mapping link" >}}

    The URL mapping settings, including the Web Control filters, display.</br>

    {{< figure src="/images/web_controls/image-manager/image_manager_url_mapping_settings.png" align="left" width="90%" alt="Url mappings settings" >}}

6. In the **Remote URL** field, modify the filters in the **images** path by performing any or all of the following operations.</br>
    - Append new filters to the filter string. Except for the Resize filter, each filter should start with `/filters:`. The filter name and one or more values follow. The filter at the end of the string ends with a backslash.
    - Modify filter values. For example, you can increase image compression, which will also result in lower quality, by decreasing the numeric value for the Quality filter.
    - Remove filters from the filter string.
9. Click **Done**.

    {{< figure src="/images/web_controls/image-manager/image_manager_click_done_modify_filters.png" align="left" width="90%" alt="Click Done when finishing modifying filters" >}}

10. On the right side of the **Edit request web control** header, click **Done**.

    {{< figure src="/images/web_controls/image-manager/image_manager_click_done_modify_web_control.png" align="left" width="90%" alt="Click Done when finishing modifying Web Control" >}}

11. Click **Apply**.

    {{< figure src="/images/web_controls/image-manager/image_manager_click_apply_web_control.png" align="left" width="90%" alt="Click Apply when finishws modifying Web Control" >}}

## Filters overview

The **Use alternate backends** action for the Web Controls fulfills two important roles. It defines the image processing filters through the remote URL. It also identifies the route to the AWS API Gateway endpoint that triggers a Lambda for {{< term "image_manager" >}}.

Each filter starts with `/filters:` except for the Resize filter. All filters uses the syntax presented in the table of [supported filters](#supported-filters). The filter name and one or more values follow. Values can be numeric, boolean, or in text, such as the names of supported file formats.

For example, this action might include the Quality filter, which changes the compression and corresponding quality of JPEG images. A value of 60% of the maximum quality would be represented as: `filters:quality(60)`.

When this action includes multiple filters, the filters are grouped and represented as a single string. While the filter order determines when {{< term "image_manager" >}} executes each filter, the processing order does not affect the results.

The last filter in the string ends with a backslash.

### Detailed example

For the Webscale Image-Manager Safari Web Control, the **Use alternate backends** action settings, which include the default filters and values, are as follows.

Route request to servers at `iq3h20n8qa.execute-api.us-east-1.amazonaws.com` with the remote url `https://`<span></span>`iq3h20n8qa.execute-api.us-east-1.amazonaws.com/image/filters:quality(60)/filters:progressive()/fit-in/1920x1080/filters:noupscale()/`

{{< figure src="/images/web_controls/image-manager/image_manager_safari_default_filters.png" align="left" width="90%" alt="Image Manager Safari Web Control default filters" >}}

#### Action settings components

{{< figure src="/images/web_controls/image-manager/image_manager_entire_detailed_example.png" align="left" width="85%" alt="Image Manager Safari Web Control filters detailed example" >}}

- `iq3h20n8qa.execute-api.us-east-1.amazonaws.com` is the AWS API Gateway endpoint
- The filters are located at the **image** subdomain of your endpoint domain
- The filters are presented as such: `/filters:quality(60)``/filters:progressive()/fit-in/1000x1080`/`filters:noupscale()`/

#### Filter results

The processed images will have the following characteristics that correspond to specific filters and their values.

{{< figure src="/images/web_controls/image-manager/image_manager_detailed_example_filter_string.png" align="left" width="85%" alt="Image Manager Safari Web Control filters string" >}}

- Quality filter, `/filters:quality(60)`: Display at 60% of the quality of the original images with a smaller file size that corresponds to the amount of compression.
- Progressive filter, `filters:progressive()`: JPEG and PNG images load immediately at a low resolution that progressively increases
after they are converted to progressive formats
- Resize filter, `fit-in/1920x1080`: Dimensions are 1920px by 1000px
- No upscale filter, `/filters:noupscale()/`: Resized if the requested dimensions are smaller than those of the original images

For general information about using Thumbor filters and detailed information about each filter, see [Getting Started](https://thumbor.readthedocs.io/en/latest/getting_started.html) and [Filters](https://thumbor.readthedocs.io/en/latest/filters.html#available-filters) for the [Thumbor documentation](https://thumbor.readthedocs.io/en/latest/index.html).

### Supported filters

{{< term "image_manager" >}} supports a subset of the Thumbor filters and the custom Progressive filter.

The default {{< term "image_manager" >}} filters are the most commonly used filters. For more information about the default filters, see [Filters](#filters).

Most often, users change filter values and not the filters. For example, the default value of the Resize filter (`fit-in`) for the {{< term "image_manager" >}} Mobile Web Control specifies resizing images to 500 pixels by 500 pixels: `/fit-in/500x500`.

You would indicate that you want images that are 450 pixels by 450 pixels by changing the filter to: `/fit-in/450x450`.

**Filter Name** | **Syntax**
-- | -- |
Color fill	| `/filters:fill(color)/`
Convolution | /`filters:convolution(1;2;1;2;4;2;1;2;1,3,false)/`
Equalize	| `/filters:equalize()/`
Format (jpeg, png, gif)	| `/filters:format(jpeg)/`
Grayscale	| `/filters:grayscale()/`
No upscale	| `/filters:no_upscale()/`
Image format `(heic, heif, jpeg, png, raw, tiff, webp)`	| /`filters:format(image_format)`
Progressive | `/filters:progressive()`
Proportion	| `/filters:proportion(0.0-1.0)/`
Quality	| /`filters:quality(0-100)/`
Resize	| `/fit-in/800x1000/`
Crop	| `/10x10:100x100/`
RGB	| `/filters:rgb(20,-20,40)/`
Resize | `/fit-in/(image_ dimensions)`
Rotate	| `/filters:rotate(90)/`
Sharpen	| `/filters:sharpen(0.0-10.0, 0.0-2.0, true/false)/`
Stretch	| `/filters:stretch()/`
Strip Exif	| `/filters:strip_exif()/`
Strip ICC	| `/filters:strip_icc()/`
Upscale	| `/filters:upscale()`
Watermark	| `/filters:watermark(bucket,key,x,y,alpha[,w_ratio[,h_ratio]])`

## Further Reading

- [Configuring CloudEDGE CDN Caching Policies](/docs/how-tos/CloudEDGE/cdn-controls/)
- [Configuring and Flushing the Site Cache](/docs/how-tos/advanced/site-cache/)
- [Creating Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
- [Managing Web Controls](/docs/how-tos/web-controls/webcontrols_manage/)
---
# How to Create a Site Splice
URL: https://docs.webscale.com/docs/how-tos/web-controls/site-splice/
Description: A walkthrough on how to create a Site Splice using a Web Control



{{% include webcontrol.md %}}

**Site Splice** allows you to build a website from multiple sources, such as microsites, multiple backends, canned content, and more. Use the **Use Alternate Backends** Web Control action to configure **Site Splice**, and to rewrite the source URL for SEO or other purposes. Some common use cases for using Site Splice include loading assets from an Amazon S3 bucket, or using [Webscale Image Manager](/docs/how-tos/web-controls/image-manager/). **Use Alternate Backend** is a final action. Final actions always run last; the order of execution of other actions is unspecified and not necessarily in the order displayed.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

{{% alert color="info" title="Prerequisite" %}}
Since you’re setting a Web Control, we recommend reading [How to Create Web Controls](/docs/how-tos/web-controls/webcontrols_create/) before following these steps.
{{% /alert %}}

### Create the Use Alternate Backend action

After you've created the **Condition** for which this Web Control action applies, click **+ Add action** to create an action for the new Web Control, which opens the Create Action dialog. To proceed, click **Select an Action**.

{{< figure src="/images/web_controls/create_action.png" alt="Webscale Create Action dialog in the control panel" >}}

A list of actions is now displayed. Select **Use Alternate Backends** to proceed.

{{< figure src="/images/web_controls/use-alternate-backends.png" width="75%" alt="Webscale Create Action dialog in the control panel, showing the **Use Alternate Backends** configuration " >}}

The configuration choices listed are:

 - **Cluster** - If you have any clusters defined for your application and wish to apply this web control for one of them, select the cluster here.
 - **Servers/Hostname**- To use an IP address, select **Servers** and enter the IP. To use a hostname or domain name, select **Hostname** and enter the domain name.
 - **Show URL Mapping** - Click **Show URL Mapping** to set this option. URL mapping allows you to change the request URL before a request is made to a backend server. Choices are:
    - **Remote URL** - Used to access backend servers. This URL may omit the scheme. If the scheme is set, then that scheme will be used to access the backend server regardless of the request scheme. When a hostname is provided in the URL, then it will be used instead of the request hostname. If a path is provided, the pathname requested from the backend server will be the path formed by joining the URL path and the request path. See the table below for examples.
    - **Relative To** - The path in the URL space of the application at which the resources obtained from the backend server are mapped. If the request url path does not begin with **Relative To** then the results may be unpredictable. The path mapping logically happens before any mapping performed by the **Remote URL** attribute. To sum up, anything added in the **Relative To** field will be removed from the URL when making the request to the alternate backend. See the table below for examples.

{{% alert title="Note:" %}}
Static files are cacheable, so if you're using Site Splice to load static assets don't forget to create a [Dynamic Site Cache](/docs/how-tos/advanced/site-cache/) rule to cover those assets. Use the **Remote URL** as the URL for the cache rule to match.
{{% /alert %}}

#### Remote URL Setting Examples

 Request URL | Remote URL | Effective URL
 ---------|----------|---------
 `https://example.com/page` | — | `https://example.com/page`
 `https://example.com/page` | `/prefix` | `https://example.com/prefix/page`
 `https://example.com/page` | `//althost.com/` | `https://althost.com/page`
 `https://example.com/page` | `//althost.com/prefix` | `https://althost.com/prefix/page`
 `https://example.com/page` | `http://althost.com/prefix` | `https://althost.com/prefix/page`

#### Relative To Setting Examples

Request URL | Relative to | Effective path
---------|----------|---------
`/` | — | `/`
`/base` | — | `/base`
`/base` | `/base` | `/`
`/base/page` | `/base` | `/page`

{{% alert title="Note:"%}}
If you're not sure what **Remote URL** to use or how to use the **Relative To** setting, please [contact support](mailto:support@webscalenetworks.com).
{{% /alert %}}

## Further Reading
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [How to Configure and Flush the Site Cache](/docs/how-tos/advanced/site-cache/)
- [How to Use a URL Map for Redirects](/docs/how-tos/web-controls/url-maps/)
---
# Web Controls How-To Guides
URL: https://docs.webscale.com/docs/how-tos/web-controls/
Description: Guides on using Web Controls



{{% include webcontrol.md %}}

You can also create sequences of these rules that can accomplish much more complex behavior, such as dynamic whitelisting or rate-limiting checkout attempts based on user behavior.
---
# Explanation
URL: https://docs.webscale.com/docs/agentic-commerce-os/ai-explanation/


---
# Support
URL: https://docs.webscale.com/docs/reference/support/
Description: Reference for Webscale's support packages, service tiers and response commitments.



Webscale support is sold in three tiers, independently of the hosting and
infrastructure product tiers.

- **Tier 1 — Essentials Support.** Standard single-ticket coverage.
- **Tier 2 — Proactive Support.** Expanded response and engineering.
- **Tier 3 — Strategic Support.** White-glove; high-availability (HA) available.

## Priority levels

Incident commitments are defined by priority:

- **P0 — Urgent.** Site down.
- **P1 — High.** Degraded performance.
- **P2 — Normal.** Non-emergency.
- **P3 — Low.** Information or minor issue.

See [Support Packages & Service Matrix](/docs/reference/support/support-packages/)
for the full tier-by-tier matrix, the DevOps add-on, and the definitions.
---
# Software
URL: https://docs.webscale.com/docs/reference/software/
Description: Reference for Webscale's software products and Platform tiers.



Webscale offers two software products.

- **CloudEDGE Security** is the Webscale security product for customers running
  their applications elsewhere. It places Webscale's security layer in front of
  an application hosted outside Webscale. It does not include the platform's
  performance and delivery features such as auto-scaling, load balancing and site
  caching.
- **Webscale Platform Software** is the full application delivery and security
  platform. It is sold in four tiers (Essentials, Advanced, Premier and Ultra)
  and is always paired with a Webscale hosting plan.

These are separate products with separate buying motions. A customer hosted
outside Webscale buys CloudEDGE Security. A customer hosting with Webscale buys a
hosting plan paired with one of the four Platform tiers. There is no upgrade path
between CloudEDGE Security and the Platform tiers; a customer moving hosting onto
Webscale transitions to a hosting and Platform pairing.

For pricing, commercial terms and the specific hosting and software pairings, see
[webscale.com](https://www.webscale.com/).

## How to read this reference

- In the comparison tables, **Included** means the feature is included and **Not
  included** means it is not. Numeric values indicate the included quantity per
  billing period.
- All metered features such as data transfer, requests, image transforms and log
  storage are billed on a consumption basis above the included allowances.
  Specific rates are published on webscale.com.
- Add-ons are optional purchases available with Platform tiers and are listed at
  the end of the comparison matrix.

See [Software Products](/docs/reference/software/software-products/) for the full
product reference, comparison matrix, per-tier detail and the features glossary.
---
# Image Catalog
URL: https://docs.webscale.com/docs/reference/images/
Description: Base VM and container images, with architectures and variants.


> All images are released simultaneously with a version number like `YYYY.nn` (e.g., `2025.33`).
> Every release publishes **all** images (even if no explicit changes). Base OS/components are not fully pinned, so most releases include upstream security/bug-fix updates. Older PHP lines (7.4, 8.1) may change less often.

## VM image families

| Family           | Architectures     | Notes |
|---               |---                |---|
| `nfs-server`     | amd64, arm64      | Storage-oriented NFS server base. |
| `web-server`     | amd64, arm64      | Host for running web workloads in a container |
| `web-server-v4`  | arm64             | Stack-based provisioner only. Host for running web workloads in a container |
| `container-host` | amd64, arm64      | Minimal host for running containers |

## Container image families

| Family     | Variant / Base            | Architectures         | Notes |
|---         |---                        |---                    |---|
| `php-fpm`  | 7.4 (alpine)              | amd64                 | EOL and unsupported upstream |
|            | 8.1 (alpine)              | amd64                 | Pinned upstream to Alpine Linux 3.21 |
|            | 8.2 (alpine)              | amd64                 | |
|            | 8.3 (alpine)              | amd64                 | |
|            | 8.4 (alpine)              | amd64                 | |
|            | 8.1 (debian)              | amd64, arm64          | |
|            | 8.2 (debian)              | amd64, arm64          | |
|            | 8.3 (debian)              | amd64, arm64          | |
|            | 8.4 (debian)              | amd64, arm64          | |
|            | 8.5 (debian)              | arm64                 | |
| `rabbitmq` | latest                    | arm64                 | |
| `varnish`  | 6.0LTS                    | arm64                 | |

## Releases
- [2026.40](/docs/reference/images/2026.40/)
- [2026.39](/docs/reference/images/2026.39/)
- [2026.38](/docs/reference/images/2026.38/)
- [2026.37](/docs/reference/images/2026.37/)
- [2026.36](/docs/reference/images/2026.36/)
- [2026.35](/docs/reference/images/2026.35/)
- [2026.34](/docs/reference/images/2026.34/)
- [2026.33](/docs/reference/images/2026.33/)
- [2026.32](/docs/reference/images/2026.32/)
- [2026.31](/docs/reference/images/2026.31/)
- [2026.30](/docs/reference/images/2026.30/)
- [2026.29](/docs/reference/images/2026.29/)
- [2026.28](/docs/reference/images/2026.28/)
- [2026.27](/docs/reference/images/2026.27/)
- [2026.26](/docs/reference/images/2026.26/)
- [2026.25](/docs/reference/images/2026.25/)
- [2026.24](/docs/reference/images/2026.24/)
- [2026.23](/docs/reference/images/2026.23/)
- [2026.22](/docs/reference/images/2026.22/)
- [2026.21](/docs/reference/images/2026.21/)
- [2026.20](/docs/reference/images/2026.20/)
- [2026.19](/docs/reference/images/2026.19/)
- [2026.18](/docs/reference/images/2026.18/)
- [2026.17](/docs/reference/images/2026.17/)
- [2026.16](/docs/reference/images/2026.16/)
- [2026.15](/docs/reference/images/2026.15/)
- [2026.13](/docs/reference/images/2026.13/)
- [2026.11](/docs/reference/images/2026.11/)
- [2026.10](/docs/reference/images/2026.10/)
- [2026.9](/docs/reference/images/2026.9/)
- [2026.8](/docs/reference/images/2026.8/)
- [2026.7](/docs/reference/images/2026.7/)
- [2026.6](/docs/reference/images/2026.6/)
- [2026.5](/docs/reference/images/2026.5/)
- [2026.4](/docs/reference/images/2026.4/)
- [2026.3](/docs/reference/images/2026.3/)
- [2026.2](/docs/reference/images/2026.2/)
- [2025.44](/docs/reference/images/2025.44/)
- [2025.41](/docs/reference/images/2025.41/)
- [2025.38](/docs/reference/images/2025.38/)
- [2025.36](/docs/reference/images/2025.36/)
- [2025.34](/docs/reference/images/2025.34/)
- [2025.33](/docs/reference/images/2025.33/)

## Registry

Obtain container images from the public ECR registry path:

```
public.ecr.aws/webscale/php-fpm
```

(Authoritative tags are visible on the ECR Public Gallery.)

## PHP image tagging convention

Tags encode **PHP version**, **base OS**, optional **architecture**, and the **release** number.

_php_[-_var_][-_YYYY.nn_]

- _php_: `7.4`, `8.1`, `8.2`, `8.3`, `8.4`
- _var_: `deb` for amd64 Debian variant; `arm64` for arm64 Debian; Alpine omits this
- _YYYY.nn_: release version (e.g., `2025.33`). Omit this to get latest release


**Examples**

```
public.ecr.aws/webscale/php-fpm:8.4-deb-2025.33
public.ecr.aws/webscale/php-fpm:8.3-2025.33
public.ecr.aws/webscale/php-fpm:8.3-arm64-2025.33
```

## How to pull

Anonymous pulls work from anywhere:

```bash
docker pull public.ecr.aws/webscale/php-fpm:<tag>
docker pull public.ecr.aws/webscale/php-fpm:8.4-deb-2025.33
```

### Optional authentication (to raise limits)

Authentication isn’t required to pull public images, but logging in to
ECR Public can raise rate/bandwidth limits. Use the AWS CLI (always
authenticate to us-east-1 for ECR Public):

```
aws ecr-public get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin public.ecr.aws
```
---
# Plans
URL: https://docs.webscale.com/docs/reference/plans/
Description: Webscale Plans


---
# Web Controls
URL: https://docs.webscale.com/docs/reference/web-controls/
Description: Web controls allow you to manage traffic by defining conditions and the specific actions to perform when those conditions are met.

---
# Introducing Application Shielding
URL: https://docs.webscale.com/docs/reference/app-shield/
Description: An introduction to Webscale Application Shielding


## Overview
**Application Shielding** is an opt-in product feature for all Webscale customers that allows a controlled isolation of the application servers in a customer's cloud account from Internet traffic. We developed this feature in response to requests from a handful of Webscale customers who wanted to configure their application servers so that all traffic reaching their application is from the Webscale proxy servers. **Application Shielding** makes it possible to eliminate direct HTTP/HTTPS traffic to the application servers from the Internet unless they are explicitly allowed by firewall settings or whitelists. It forces all other traffic to be routed through the Webscale proxies, better insulating the application from malicious attacks.

## Background
Webscale's application shielding implementation utilizes the underlying cloud provider capabilities to filter the traffic hitting the application servers. It is a fully integrated solution that assimilates the differences in cloud providers. It presents a simple, unified control to end-users that makes it easier for them to enable this extra layer of protection for their servers.

While we intend the control of this feature to be simple, we expect any user attempting to enable or disable **Application Shielding** for their applications to have a basic understanding of networking and firewall concepts. This feature is currently only supported for the AWS and the Google Cloud providers, so to make use of this security feature, the application servers must be hosted in one of those two cloud provider accounts.

Using _server blueprints_, the Webscale **Application Shield** leverages Google Cloud firewalls or AWS security groups, depending on the cloud provider you use.

{{% alert title="Firewalls and Security Groups" %}}
Firewalls in Google Cloud and security groups in AWS are fundamental networking resources in the cloud provider account that make the **Application Shielding** feature possible. Both firewalls and security groups provide a way for users to configure and control access to their application servers.
{{% /alert %}}

#### Application Server Blueprints
Webscale orchestrates any auto-scaling of application servers as dictated by the demands placed on the application by Internet traffic. A fundamental aspect of this auto-scaling is what we refer to as _server blueprints_. Server blueprints allow a Webscale customer to specify the precise configuration used to create additional application servers when needed.

Prior to the release of the **Application Shielding** feature, server blueprints allowed users to specify only the server image (operating system and software), server placement (cloud provider region/zone), and the instance type (machine capabilities). This feature release enhances these capabilities to include additional cloud provider resources in the server blueprints, including things like network/VPC, subnet for both Google Cloud and AWS, network tags (Google Cloud only), and security groups (AWS only).
These new features make it possible for a user to create server blueprints with networking attributes that allow access control to any servers created by the Webscale auto-scaling solution.

#### AWS Security Groups
AWS security groups allow users to create a set of ingress and egress rules to control traffic to servers that are associated with the security group. Security groups determine how traffic flows to and from servers in the network and all subnets of the network. Each AWS VPC (network) is associated with a security group. For more about AWS security groups, please see the [AWS Security Group Rules Reference guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html).

The **Application Shielding** feature manipulates the ingress rules on a user identified security group by adding/removing IP addresses or address blocks to put access rules into effect. Any rules added by the Webscale Application Shield to this security group are annotated with a specific description string: `webscale-app-shielding-<n>`, where `n` is an integer that grows with every new rule added by the system. When **Application Shielding** is disabled, all the ingress rules with such a description are removed by the system automatically.

{{% alert title="Things to note:" %}}
1. The security group that you configure for use with **Application Shielding** must already exist in the cloud provider account and the Webscale **Application Shield** must have access to modify the rules in the group.
2. It is the responsibility of the user to make sure that the security group rules actually impact traffic to the application servers. To do this, ensure that you create the server blueprints as [described above](#aws-security-groups).
3. Any rules that exist in the security group that include the description substring `webscale-app-shielding-<n>` are subject to deletion by the Webscale product. Therefore, rules that you don't want to be edited by the Webscale **Application Shield** must not include such a description.
{{% /alert %}}

#### Google Cloud Firewalls
Google Cloud firewalls provide the capability of allowing/restricting access to the application servers hosted in the Google Cloud account. Google Cloud firewalls are always associated with a network, and the firewall specification allows a user to specify which servers in the network are covered by the firewall rules. Accomplish this by setting a _target_ property on the firewall. One way to specify these targets is by the creation of network tags (arbitrary strings). When servers in the network are created with the same tags, the firewall rules apply to them. For more about Google Cloud Firewalls, please see the [Google Cloud Firewall rules overview](https://cloud.google.com/vpc/docs/firewalls).

The **Application Shielding** feature requires that a firewall is identified and selected by the user to shield application servers running in the Google Cloud infrastructure. The user must set the priority of this designated firewall lower than any other firewalls that are applied independently of **Application Shielding**. Webscale **Application Shielding** manipulates the specific firewall identified for **Application Shielding** and updates the rules as needed.

{{% alert title="Things to note:" %}}
1. For **Application Shielding** to work as expected, the user must not manually edit the firewall designated for **Application Shielding**. Any changes are liable to be overwritten by the **Application Shield**.
2. The user has the responsibility to ensure the firewall defines its targets appropriately, so the application servers to be protected are indeed covered by the rules in the firewall.
{{% /alert %}}

## Further reading

- [Configuring Application Shielding](/docs/how-tos/general/shielding/)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [Editing the Allowlist](/docs/how-tos/security/whitelist/)
- [Editing the Blocklist](/docs/how-tos/security/blacklist/)
---
# Webscale Shared Responsibility Security and Operational Model
URL: https://docs.webscale.com/docs/reference/shared-responsibilities/magento/
Description: A reference for Webscale Shared Responsibility Security and Operational Model


The Webscale Managed Platform follows a shared responsibility model. This structure ensures that while Webscale manages the underlying infrastructure, security, and performance at the platform layer, the Merchant and their Systems Integrator (SI) retain control over the application code, custom logic, and business configurations.

---

## **1\. Executive Summary & Strategic Recommendations**

**Summary:** This section outlines the overarching goal of the shared model: maximizing uptime and security by clearly defining boundaries. Webscale handles the "plumbing" (Infrastructure/PaaS), while the Merchant/SI handles the "storefront" (Application/Code).

**Strategic Recommendations:**

* **Patching:** Establish a 48-hour window for applying "Critical" application patches released by the software vendor (Magento/Shopware).
* **Automation:** Utilize Webscale’s Predictive Auto-scaling to handle traffic surges rather than relying on manual intervention.
* **Security:** Leverage Webscale CloudEdge for "Edge-side" security (WAAP) to stop threats before they hit the origin server.

---

## **2\. Security RACI**

**Summary:** Security is a multi-layered approach. Webscale secures the perimeter and the operating system, while the Merchant is responsible for securing the data and the application-level access points.

| Security |  |  |
| :---- | ----- | :---: |
| Task/Responsibility (from security.xlsx) | Webscale (inferred RACI) | Webscale (with Infra) |
| Applying infrastructure patches | C,I | R |
| Applying patches to supporting services (e.g., Nginx or MySQL) | R | R |
| Defining origin WAF rules | R | R |
| Defining CDN WAF rules | A | R |
| Deploying platform WAF rules | R | R |
| Deploying CDN WAF rules | A | R |
| Fixing core bugs in cloud infrastructure code | C | N/A |
| Releasing cloud infrastructure patches | C | N/A |
| Scaling (compute and storage) | R | R |
| Scaling (PaaS and grid) | R | R |
| Ensuring access to source code | R,C | R,C (This is tied to the customer's repo) |
| Installing Webscale cloud infrastructure CLI tool | I | N/A |
| Adding cloud infrastructure configuration files to repository | I | N/A |
| Creating a project for the merchant (onboarding UI) | R | R |
| Connecting repositories to cloud infrastructure | R | R |
| Configuring the source repository | R | R |
| Creating a user for the release manager (onboarding UI) | R | R |
| Deploying code into production | I | R,I |
| Deploying code into staging | I | R,I |
| Remediating cloud infrastructure PCI scans | C,I | R |
| Remediating PaaS PCI scans | R | R |
| Managing OS and platform secrets | R | R |
| Managing cloud infrastructure encryption keys | R | R |
| Scanning customized cloud infrastructure instances | R | R |
| Managing support access controls (Teleport) | R | R |
| Controlling merchant support and access | R | R |
| Annual testing DR plan and backup and restore | R | R |
| Annual testing and documentation of disaster recovery plan | R | R |

## **3\. Coding and Development**

**Summary:** This section defines the ownership of the code lifecycle. Webscale provides the environment, but the integrity, quality, and security of the code residing in that environment are the responsibility of the developer.

| Coding and Development |  |  |
| :---- | ----- | :---: |
| Task/Responsibility | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Publishing updates and patches to core | I | R (This only applies to Webscale systems, not the customer's Magento application) |
| 2\. Availability and patching of the file system | R | R |
| 3\. Publishing updates and patches to ECE-Tools | I | I |
| 4\. Core Application Quality | I | R (This only applies to Webscale systems, not the customer's Magento application) |
| 5\. Availability of repo.magento.com | I | C |
| 6\. Availability of Cloud Git server | I | C |
| 7\. Other merchant-selected Code repositories | I | C,I |
| 8\. Making Cloud Docker containers available for download | R | R |
| 9\. Deployment and setup of Cloud Docker (optional) | I | I |
| 10\. Any other local development setup | I | I |
| 11\. Ongoing quality and updating of ECE Tools | I | I |
| 12\. Installing the latest ECE Tools version | I | I |
| 13\. Custom Magento modules and code | I | I |
| 14\. Extensions | I | I |
| 15\. Custom Integrations | I | I |
| 16\. Configuration of build and static content deployment | I | I |
| 17\. Building and executing deployment governance process | I | I |
| 18\. Deploying to Staging environment | I | C,I |
| 19\. Deploying to Production environment | I | C,I |
| 20\. Production rollbacks | R,I | R,I |
| 21\. Synchronizing data between environments | R | R |
| 22\. Installing updates and patches to ECE-Tools | I | I |
| 23\. Installing updates and patches to Magento core | I | I |
| 24\. Customized Magento application and associated websites | I | I |
| 25\. Core Application tuning and optimization | I | I |
| 26\. Custom code tuning and optimization | I | I |
| 27\. Custom code | I | N/A |
| 28\. Load Testing | R,I | R,I (If purchased with us or they have their own) |
| 29\. Performance testing | I | R,I (If purchased with us or they have their own) |
| 30\. Rotating Logs | R | R |
| 31\. Custom application | I | N/A |
| 32\. Availability of New Relic services | A | C,I (Customer has their own New Relic) |
| 33\. Setting up New Relic Alerts | R,I | R,I (We will only set up the access keys; the customer will need to set up the alerts) |
| 34\. Deploying New Relic agent on PaaS Servers | R | R |
| 35\. Debugging and issue isolation | R | R |
| 36\. Timely support of debugging and issue isolation process | R | R |

## **4\. Application and Service Configuration**

**Summary:** While Webscale ensures the availability of services like PHP, Redis, MySQL, RabbitMQ, and OpenSearch, the specific configuration and usage of these services to meet business logic requirements are controlled by the SI.

| Application and Service Configuration |  |  |
| :---- | ----- | :---: |
| Task/Responsibility | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Application configuration | R,I | R,I (Webscale \- Adding the Domain in the control panel | Settings on Magento has to be done by the customer) |
| 2\. Adding domains to the application (Base URLs) | R,I | R,I (Webscale \- Adding the Domain in the control panel | Settings on Magento has to be done by the customer) |
| 3\. Configuring PaaS to use supported Service versions (PHP, Redis) | R | R |
| 4\. Availability of default cron jobs | R | R,C (Customers cannot add their own cron jobs) |
| 5\. Ongoing quality of custom cron jobs | R | C,I (This is important as customer-provided crons can and have caused issues by not completing in time or consuming too many resources) |
| 6\. Availability of RabbitMQ service | R | R |
| 7\. Configuration of default RabbitMQ settings | R | R |
| 8\. Ongoing quality and patching of RabbitMQ | R | R |
| 9\. Submit a service request to install a compatible RabbitMQ version | A | C,R (If a customer requires it we install it.) |
| 10\. Availability of PHP | R | R |
| 11\. Configuration of default PHP settings | R | R |
| 12\. Configuration of custom PHP settings | R | R |
| 13\. Configuration of YAML file to align PHP versions | R,I | N/A |
| 14\. Availability of Galera and MariaDB services | R | R (We also support MySQL) |
| 15\. Ongoing maintenance of default database settings | R | R |
| 16\. Ongoing maintenance of merchant data and modified settings | I | C |
| 17\. Configuration of Galera and MySQL | R | R |
| 18\. Ongoing quality and patching of Galera and MariaDB | R | R |
| 19\. Ongoing infrastructure optimization | R | R |
| 20\. Identifying and fixing slow queries | C,I | C,I (Non-service-impacting issues remain the customer's responsibility) |
| 20a\. Identifying and fixing problematic queries |  | R,C (Only for service-impacting issues) |
| 21\. Submit a service request to install a compatible MariaDB version | A | C,R (If a customer requires it we install it.) |
| 22\. Setting and maintaining merchant-specific data retention policies | I | C |
| 23\. Availability and Quality of CDN | R | R |
| 24\. Fastly service configuration (via Extension / API) | R,I | I |
| 25\. Fastly Extension Quality | I | I |
| 26\. Fastly Integration VCL Snippets Quality | R,I | I |
| 27\. Page Cache optimization | R | R |
| 28\. Adding domains to services, to CDN, and to infrastructure | R | R |
| 29\. Custom VCL Snippets | R,I | I |
| 30\. WAF & WAF Rules | A | R,C (Customer has the ability to manage as well) |
| 31\. Availability of Redis service | R | R |
| 32\. Configuration of default Redis settings | R | R |
| 33\. Ongoing quality and patching of Redis | R | R |
| 34\. Submit a service request to install a compatible Redis version | A | C,R (If a customer requires it we install it.) |
| 35\. Availability of Elasticsearch | R | R |
| 36\. Configuration of default Elasticsearch settings | R | R |
| 37\. Submit a service request to install a compatible Elasticsearch version | A | C,R (If a customer requires it we install it.) |
| 38\. Availability of SendGrid email service and its integration | R | R |
| 39\. Monitor merchant’s SendGrid usage against limits | R | R |
| 40\. Merchant responsible for using the service for transactional emails only | R | R |
| 41\. Configuring optional third-party email services | I | I |
| 42\. Availability and quality of third party services | I | I |

## **5\. Commerce Services Extensions**

**Summary:** Webscale allows for best-of-breed integrations. The responsibility for selecting, integrating, and maintaining these third-party services lies with the Merchant.

| Commerce Services Extensions |  |  |
| :---- | ----- | :---- |
| Task/Responsibility | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Availability of the Advanced Reporting Service | I | I (If customer has their own advanced reporting services we will work with them) |
| 2\. Configuration of Advanced Reporting complies with Terms & Conditions | I | I (If customer has their own advanced reporting services we will work with them) |
| 3\. Availability of Business Intelligence (MBI) services | I | I (If customer has their own advanced reporting services we will work with them) |
| 4\. MBI Data Synchronization processes | I | I (If customer has their own advanced reporting services we will work with them) |
| 5\. Detecting MBI synchronization issues | I | I (If customer has their own advanced reporting services we will work with them) |
| 6\. Configuring MBI Data Synchronization (for various platforms) | I | I (If customer has their own advanced reporting services we will work with them) |
| 7\. Availability of Product Recommendations service | I | I (If customer has their own advanced reporting services we will work with them) |

## **6\. Network Services**

**Summary:** Focuses on the "Edge" of the network. Webscale manages the delivery and acceleration of content, while the Merchant manages the content itself and the domains.

| Network Services |  |  |
| :---- | :---: | ----- |
| Task/Responsibility | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Availability and Quality of Image Optimization | R | R |
| 2\. Configuration of Image Optimization | R | R |
| 3\. SSL Dedicated Certificate \- expiration | R | R,I (If customer supplies SSL) |
| 4\. Provisioning SSL Certificates | R | R,I (If customer supplies SSL) |
| 5\. Purchasing and Maintaining EV/Specific SSL cert and provide to Adobe | R,I | R,I (If customer supplies SSL) |
| 6\. Availability & Configuration of WAF | A | R |
| 7\. Addressing WAF Rule False Positives | R | R,C (Customer Needs to validate) |
| 8\. Reporting WAF Rule False Positives | I | C |
| 9\. WAF Rule Tuning | R | R,C (Customer Needs to validate) |
| 10\. WAF/CDN Logs | R | R,C (Customer Needs to validate) |
| 11\. Proactive IP Blocking | R | R |
| 12\. Bot Protection | R | R,I (If customer purchases bot manager) |
| 13\. DDoS detection \- layer 3-4 | R | R |
| 14\. DDoS detection \- layer 7 | A | R |
| 15\. DDoS response | A | R |
| 16\. Configuring and maintaining PrivateLink connections (Adobe-owned VPC) | R,I | R,I (If customer has own VPC and or Peering) |
| 17\. Configuring and maintaining PrivateLink connections (Merchant-owned VPC) | R,I | R,I (If customer has own VPC and or Peering) |
| 18\. Availability of SSH (Non-PrivateLink) | R | R,I (If customer has own VPC and or Peering) |
| 19\. Configuration of PrivateLink Inbound to Cloud Service endpoint | R,I | R,I (If customer has own VPC and or Peering) |
| 20\. Acceptance of PrivateLink Inbound to Cloud Service endpoint | R,I | R,I (If customer has own VPC and or Peering) |
| 21\. Configuration of PrivateLink Inbound to Merchant’s VPC Service endpoint | R,I | R,I (If customer has own VPC and or Peering) |
| 22\. Acceptance of PrivateLink Inbound to Merchant’s VPC Service endpoint | R,I | R,I (If customer has own VPC and or Peering) |
| 23\. Configuration of PrivateLink integrations (endpoint to account) | R,I | R,I (If customer has own VPC and or Peering) |
| 24\. Configuration of merchant-owned VPC for PrivateLink endpoint | R,I | R,I (If customer has own VPC and or Peering) |

## **7\. System and Infrastructure**

**Summary:** This is the core of the Webscale value proposition. We ensure the servers are up, scaled, and backed up based on standard lifecycle policies.

| System and infrastructure |  |  |
| :---- | :---: | :---: |
| Task/Responsibility | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Availability of Nginx | A | R |
| 2\. Configuration of Nginx | R | R |
| 3\. Ongoing quality and patching of Nginx | A | R |
| 4\. Availability of Operating System | A | R |
| 5\. Ongoing quality and patching of Operating System | A | R |
| 6\. Availability of snapshot and backup process | A | R |
| 7\. Scheduling backups for Pro Staging and Production | R | R |
| 8\. Scheduling backups for Starter and Pro Integration environments | R | R |
| 9\. Availability of HA / Failover | A | R |
| 10\. Availability of CPU resources, data center, disk space | A | R |
| 11\. Availability and execution of surge capacity or emergency upsizing | A | R |
| 12\. Requesting surge capacity | C,I | C,I |
| 13\. Monitoring vCPU usage against the limits | R | R |
---
# Webscale Shared Responsibility Security and Operational Model - Shopware
URL: https://docs.webscale.com/docs/reference/shared-responsibilites/shopware/
Description: A reference for Webscale Shared Responsibility Security and Operational Model for Shopware

**Last Update: March 4, 2026**

The Webscale Managed Platform for Shopware is a platform-as-a-service (PaaS) designed to support the unique architecture of Shopware 6\. This model ensures that while Webscale handles the high-performance infrastructure and Symfony-optimized environment, the Merchant and Systems Integrator (SI) manage the application logic and customer experience.

---

## **1\. Executive Summary & Strategic Recommendations**

**Summary:** For Shopware merchants, the shared model focuses on the stability of the Symfony framework and the performance of the Shopware Storefront/Admin. Webscale manages the underlying stack (Linux/PHP/MySQL), while the Merchant/SI manages the Shopware core and third-party extensions.

**Strategic Recommendations:**

* **Version Management:** Ensure the SI proactively manages Shopware 6 "Minor" and "Patch" releases to maintain compatibility with the Webscale environment.
* **Performance:** Utilize Webscale's optimized Redis configuration for Shopware’s high-frequency caching requirements.
* **Extension Security:** Audit all Shopware "Apps" and "Plugins" regularly, as these are the most common vectors for application-level vulnerabilities.

---

## **2\. Security RACI (Shopware)**

**Summary:** Webscale protects the "container" and the "perimeter" (WAF/DDoS), while the Merchant secures the "content" and "code" within Shopware.

| Security |  |  |  |
| :---- | :---- | ----- | :---- |
| Task/Responsibility  | Shopware (RACI) | Webscale (inferred RACI) | Webscale (with Infra) |
| Applying Shopware patches on cloud infrastructure | C | C,I | R |
| Applying patches to supporting services (e.g., Nginx or MySQL.) | R | R | R |
| Defining origin WAF rules | R | R | R |
| Defining CDN WAF rules | A | A | R |
| Deploying platform WAF rules | R | R | R |
| Deploying CDN WAF rules | A | A | R |
| Fixing core bugs in Shopware on cloud infrastructure code | R | C | N/A |
| Releasing Shopware on cloud infrastructure patches | R | C | N/A |
| Scaling (compute and storage) | R | R | R |
| Scaling (PaaS and grid) | R | R | R |
| Ensuring access to source code | R | R,C | R,C (This is tied to the customer's repo) |
| Installing Shopware on cloud infrastructure CLI tool | R | I | N/A |
| Adding Shopware on cloud infrastructure configuration files to repository | C | I | N/A |
| Creating a project for the merchant (onboarding UI) | R | R | R |
| Connecting repositories to Shopware on cloud infrastructure | R | R | R |
| Configuring the source repository | R | R | R |
| Creating a user for the release manager (onboarding UI) | R | R | R |
| Deploying code into production | R | I | R,I |
| Deploying code into staging | R | I | R,I |
| Remediating Shopware on cloud infrastructure PCI scans | R | C,I | R |
| Remediating PaaS PCI scans | R | R | R |
| Managing OS and platform secrets | R | R | R |
| Managing Shopware on cloud infrastructure encryption keys | R | R | R |
| Scanning customized Shopware on cloud infrastructure instances | R | R | R |
| Managing support access controls (Teleport) | R | R | R |
| Controlling merchant support and access | R | R | R |
| Annual testing and documentation of Shopware DR plan and backup and restore | R | R | R |
| Annual testing and documentation of disaster recovery plan | R | R | R |

---

## **3\. Coding and Development (Symfony/Shopware)**

**Summary:** Ownership of the Shopware codebase. Webscale provides the platform for deployment, but the SI is responsible for the performance and stability of custom Twig templates and Symfony controllers.

| Coding and Development |  |  |  |
| :---- | :---- | ----- | :---- |
| Task/Responsibility  | Shopware (RACI) | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Publishing updates and patches to Shopware | RA | I | R (This only applies to Webscale systems not the customers Shopware application) |
| 2\. Availability and patching of the file system | RP | R | R |
| 4\. Core Shopware Application Quality | RA | I | R (This only applies to Webscale systems not the customers Shopware application) |
| 6\. Availability of Shopware on Cloud Git server | RO | not responsible | not responsible |
| 7\. Other merchant-selected Code repositories | R | I | C,I |
| 8\. Making Cloud Docker containers available for download | R | R | R |
| 9\. Deployment and setup of Cloud Docker (optional) | RA | I | I |
| 10\. Any other local development setup | RO | I | I |
| 13\. Custom Shopware modules and code | RE | I | I |
| 14\. Extensions | RC | I | I |
| 15\. Webscale Extension | CI | RA | RA |
| 15\. Custom Integrations | R | I | I |
| 16\. Configuration of build and static content deployment | RC | I | I |
| 17\. Building and executing deployment governance process | RB | I | I |
| 18\. Deploying to Staging environment | RD | I | C,I |
| 19\. Deploying to Production environment | RD | I | C,I |
| 20\. Production rollbacks | R | R,I | R,I |
| 21\. Synchronizing data between environments | I | R | R |
| 23\. Installing updates and patches to Shopware core (Major Version Upgrade) | RC | CI | CI |
| 24\. Customized Shopware application and associated websites | RC | I | I |
| 25\. Core Application tuning and optimization | RC | I | R? (Need to find the team that does this type of work. Currently, support does not touch code) |
| 26\. Custom code tuning and optimization | RC | I | R? (Need to find the team that does this type of work. Currently, support does not touch code) |
| 27\. Custom Shopware code | RL | I | N/A |
| 28\. Load Testing | RT | R,I | R,I (If purchased with us or they have their own) |
| 29\. Performance testing | RP | I | R,I (If purchased with us or they have their own) |
| 30\. Rotating Logs | R | R | R |
| 31\. Custom Shopware application | RA | I | N/A |
| 32\. Availability of New Relic services | RA | A | C,I (Customer has their own New Relic) |
| 33\. Setting up New Relic Alerts | RS | R,I | R,I (We will only set up the access keys; customer will need to set up the alerts) |
| 34\. Deploying New Relic agent on PaaS Servers | RD | R | R |
| 35\. Debugging and issue isolation | RR | R | R |
| 36\. Timely support of debugging and issue isolation process | R | R | R |

---

## **4\. Application and Service Configuration**

**Summary:** Webscale ensures the availability of the Shopware "sidecars" (Redis, MySQL, RabbitMQ), while the SI configures how Shopware interacts with them.

| Application and Service Configuration |  |  |  |
| :---- | :---- | ----- | :---- |
| Task/Responsibility  | Shopware (RACI) | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Application configuration | R | R,I | R,I (Webscale \- Adding the Domain in the control panel | Settings on Shopware has to be done by the customer) |
| 2\. Adding domains to the Shopware application | R | R,I | R,I (Webscale \- Adding the Domain in the control panel | Settings on Shopware has to be done by the customer) |
| 3\. Configuring PaaS to use supported Service versions (PHP, Redis) | RA | R | R |
| 4\. Availability of default cron jobs | R | R | R,C (Customers cannot add their own Cron Jobs) |
| 5\. Ongoing quality of custom cron jobs | RA | R | C, I (This is important as customer-provided crons can and have caused issues by not completing in time or consuming too many resources) |
| 6\. Availability of RabbitMQ service | R | R | R |
| 7\. Configuration of default RabbitMQ settings | R | R | R |
| 8\. Ongoing quality and patching of RabbitMQ | R | R | R |
| 9\. Submit a service request to install a compatible RabbitMQ version | RA | A | C,R (If customer requires it we install it.) |
| 10\. Availability of PHP | R | R | R |
| 11\. Configuration of default PHP settings | R | R | R |
| 12\. Configuration of custom PHP settings | R | R | R |
| 14\. Availability of MariaDB services | R | R | R (We also support MySQL) |
| 15\. Ongoing maintenance of default database settings | R | R | R |
| 16\. Ongoing maintenance of merchant data and modified settings | R | I | C |
| 17\. Configuration of MySQL | R | R | R |
| 18\. Ongoing quality and patching of MySQL/MariaDB | R | R | R |
| 19\. Ongoing infrastructure optimization | R | R | R |
| 20\. Identifying and fixing slow queries | R | C,I | C,I (Non-service-impacting issues remain the customer's responsibility) |
| 20 a. Identifying and fixing problematic queries |  |  | R,C (Only for Service impacting issues) |
| 21\. Submit a service request to install a compatible MariaDB version | R | A | C,R (If customer requires it we install it.) |
| 22\. Setting and maintaining merchant-specific data retention policies | RA | I | C |
| 23\. Availability and Quality of CDN | R | R | R |
| 24\. Fastly service configuration (via Extension / API) | R | CI | CI |
| 25\. Fastly Extension Quality | R | I | I |
| 26\. Fastly Integration VCL Snippets Quality | R | CI | CI |
| 27\. Page Cache optimization | R | RC | RC |
| 28\. Adding domains to services, to CDN, and to infrastructure | R | R | R |
| 29\. Custom VCL Snippets | R | R,I | R,I |
| 30\. WAF & WAF Rules | RA | A | R,C (Customer has the ability to manage as well) |
| 31\. Availability of Redis service | R | R | R |
| 32\. Configuration of default Redis settings | R | R | R |
| 33\. Ongoing quality and patching of Redis | R | R | R |
| 34\. Submit a service request to install a compatible Redis version | RA | A | C,R (If customer requires it we install it.) |
| 35\. Availability of ElasticSearch | R | R | R |
| 36\. Configuration of default ElasticSearch settings | R | R | R |
| 37\. Submit a service request to install a compatible ElasticSearch version | RA | A | C,R (If customer requires it we install it.) |
| 38\. Availability of SendGrid email service and its integration | R | R | R |
| 39\. Monitor merchant’s SendGrid usage against limits | R | R | R |
| 40\. Merchant responsible for using the service for transactional emails only | R | R | R |
| 41\. Configuring optional third-party email services | RA | I | I |
| 42\. Availability and quality of third party services | R | I | I |

---

## **5\. Shopware Services & Extensions**

**Summary:** Shopware often utilizes external SaaS services. The Merchant is responsible for the commercial relationship and the integration logic for these external tools.

| Commerce Services Extensions |  |  |  |
| :---- | :---- | ----- | :---- |
| Task/Responsibility  | Shopware (RACI) | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Availability of the Advanced Reporting Service | R | I | I (If customer has their own advanced reporting services we will work with them) |
| 2\. Configuration of Advanced Reporting complies with Terms & Conditions | RA | I | I (If customer has their own advanced reporting services we will work with them) |
| 3\. Availability of Shopware Business Intelligence (MBI) services | R | I | I (If customer has their own advanced reporting services we will work with them) |
| 4\. MBI Data Synchronization processes | R | I | I (If customer has their own advanced reporting services we will work with them) |
| 5\. Detecting MBI synchronization issues | R | I | I (If customer has their own advanced reporting services we will work with them) |
| 6\. Configuring MBI Data Synchronization (for various platforms) | R | I | I (If customer has their own advanced reporting services we will work with them) |
| 7\. Configuring MBI Data Synchronization to Shopware Cloud Pro | RA | I | I (If customer has their own advanced reporting services we will work with them) |
| 8\. Availability of Product Recommendations service | R | I | I (If customer has their own advanced reporting services we will work with them) |

---

## **6\. Network Services**

**Summary:** Managing the flow of traffic to the Shopware store. Webscale manages the acceleration and security at the edge.

| Network Services |  |  |  |
| :---- | :---- | ----- | :---- |
| Task/Responsibility  | Shopware (RACI) | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Availability and Quality of Image Optimization | R | R | R |
| 2\. Configuration of Image Optimization | R | R | R |
| 3\. SSL Dedicated Certificate \- expiration | R | R | R,I (If customer supplies SSL) |
| 4\. Provisioning SSL Certificates | R | R | R,I (If customer supplies SSL) |
| 5\. Purchasing and Maintaining EV/Specific SSL cert and provide to Shopware | RA | R,I | R,I (If customer supplies SSL) |
| 6\. Availability & Configuration of WAF | R | A | R |
| 7\. Addressing WAF Rule False Positives | R | R | R,C (Customer Needs to validate) |
| 8\. Reporting WAF Rule False Positives | R | I | C |
| 9\. WAF Rule Tuning | NOT SUPPORTED | R | R,C (Customer Needs to validate) |
| 10\. WAF/CDN Logs | R | R | R,C (Customer Needs to validate) |
| 11\. Proactive IP Blocking | R | R | R |
| 12\. Bot Protection | R | R | R,I (If customer purchases bot manager) |
| 13\. DDOS detection \- layer 3-4 | R | R | R |
| 14\. DDOS detection \- layer 7 | R | A | R |
| 15\. DDOS response | R | A | R |
| 16\. Configuring and maintaining PrivateLink connections (Shopware-owned VPC) | R | R,I | R,I (If customer has own VPC and or Peering) |
| 17\. Configuring and maintaining PrivateLink connections (Merchant-owned VPC) | RA | R,I | R,I (If customer has own VPC and or Peering) |
| 18\. Availability of SSH (Non-Private Link) | R | R | R,I (If customer has own VPC and or Peering) |
| 19\. Configuration of PrivateLink Inbound to Shopware Cloud Service endpoint | R | R,I | R,I (If customer has own VPC and or Peering) |
| 20\. Acceptance of PrivateLink Inbound to Shopware Cloud Service endpoint | R | R,I | R,I (If customer has own VPC and or Peering) |
| 21\. Configuration of PrivateLink Inbound to Merchant’s VPC Service endpoint | R | R,I | R,I (If customer has own VPC and or Peering) |
| 22\. Acceptance of PrivateLink Inbound to Merchant’s VPC Service endpoint | R | R,I | R,I (If customer has own VPC and or Peering) |
| 23\. Configuration of PrivateLink integrations (endpoint to account) | R | R,I | R,I (If customer has own VPC and or Peering) |
| 24\. Configuration of merchant-owned VPC for PrivateLink endpoint | R | R,I | R,I (If customer has own VPC and or Peering) |

---

## **7\. System and Infrastructure**

**Summary:** The foundational layer. Webscale guarantees that the resources required to run Shopware are available, redundant, and scalable.

| System and infrastructure |  |  |  |
| :---- | :---- | :---- | :---- |
| Task/Responsibility  | Shopware (RACI) | Webscale (inferred RACI) | Webscale (with Infra) |
| 1\. Availability of Nginx | R | A | R |
| 2\. Configuration of Nginx | R | R | R |
| 3\. Ongoing quality and patching of Nginx | R | A | R |
| 4\. Availability of Operating System | R | A | R |
| 5\. Ongoing quality and patching of Operating System | R | A | R |
| 6\. Availability of snapshot and backup process | R | A | R |
| 7\. Scheduling backups for Pro Staging and Production | R | R | R |
| 8\. Scheduling backups for Starter and Pro Integration environments | RA | R | R |
| 9\. Availability of HA / Failover | R | A | R |
| 10\. Availability of CPU resources, data center, disk space | R | A | R |
| 11\. Availability and execution of surge capacity or emergency upsizing | R | A | R |
| 12\. Requesting surge capacity | R | C,I | C,I |
| 13\. Monitoring vCPU usage against the limits | R | R | R |
---
# Shutdown hooks
URL: https://docs.webscale.com/docs/reference/shutdown-hooks/
Description: Controlling container shutdown with custom scripts


This page describes how to configure and use Webscale’s shutdown hook mechanism
so your application servers can finish in-flight work cleanly before they are
destroyed.

The goal: when Webscale needs to terminate a server (scale in, rolling deploy,
or manual destroy), your application gets a clear signal, some time to react,
and the platform waits (up to a limit) before terminating the server.

Scope: This applies to managed or unmanaged clusters running a `web-server`
image of version 2025.44 or later.

### High-level behavior

When a server is selected for termination:

1. Webscale initiates termination of the server instance through its cloud provider.
2. A systemd shutdown unit on the host runs the Webscale container shutdown handler.
3. The handler iterates over all running application containers on that host.
4. For each container:
 * It runs /hooks/shutdown inside the container if that file exists and is executable.
 * It waits for the hook to exit, subject to a time out of 10 minutes for all hooks.
5. Once all hooks have completed or timed out, the platform proceeds with normal shutdown and destroys the server.

The actions performed by the shutdown hook are entirely determined by the
application containers that are run on the `web-server` container host as
determined by the "bootstrap" configuration.

Important:
> The shutdown hook is triggered when the server is actually being destroyed,
> not when a deployment becomes “old” or is no longer receiving primary traffic.
> Old deployments may still perform work until their destruction is requested.
> If it is necessary to begin the shutdown for deployments in managed clusters
> as soon as they are no longer needed, a destroy delay of 0 must used.

### What the shutdown hook is for

Use the hook to:

- Stop accepting new work.
- Let in-flight requests complete.
- Drain queues / background jobs.
- Persist state that would otherwise be lost.
- Emit final logs / metrics for the node.

Do not use the hook to:
- Keep the server alive indefinitely.
- Perform long-running maintenance that should be done elsewhere.
- Start new long-lived background jobs.

If all hooks do not finish within 10 minutes, Webscale will continue shutdown
anyway and the instance will be terminated. The cloud provider may terminate
the instance sooner, so it is best for a hook to complete work within a minute
or less to ensure that it is not forcibly terminated.

### Implementing a hook inside a container

On each container, if `/hooks/shutdown` exists and is executable, it will be run
as root. Standard output and error are written to the `container-shutdown`
service unit logs.

#### Minimal example

A very simple shutdown hook that terminates a scheduler process and then waits
for it to complete:

```
#!/bin/sh

# Shutdown hook to terminate the scheduler process. The scheduler responds to
# SIGTERM causing it to stop scheduling new work and only exits when all
# in-flight work is done.

PID="$(pidof scheduler)"
if [ -n "$PID" ]; then
  kill $PID

  while kill -0 $PID; do
    sleep 1
  done
fi
```

Make shutdown.sh executable in your repository and ensure it is copied in
your Dockerfile to the correct location.

```
COPY shutdown.sh /hooks/shutdown
```

### FAQ

Q: Will this hook run when the deployment is made inactive but not destroyed?

A: No. It runs when the server is being terminated (scale-in, deployment
expired, or manual destroy), not when a deployment just becomes non-current.

Q: Can I rely on SSH / network / Docker being available during the hook?

A: Yes, during the controlled shutdown window the host is still in a normal
running state: Docker, networking, and SSH remain available while your hook
runs. Once the hook finishes or times out, shutdown continues and these services
go away. Any SSH sessions are terminated at the initiation of shutdown, however,
so any diagnosis must be done on a new session.

Q: Can I keep the instance alive indefinitely by never exiting the hook?

A: No. The process of terminating the server with the cloud provider has already
begun to terminate the server. All cloud providers will eventually power off
hosts that do not shutdown promptly.

Q: Can I run different shutdown behavior per container type?

A: Yes. Each container image can provide its own hook implementation. Containers
without the script will simply be terminated normally.
---
# Ubuntu Package Security & Backporting Policy
URL: https://docs.webscale.com/docs/reference/ubuntu-package-security-and-backporting-policy/
Description: This document outlines Webscale’s technical strategy for managing software packages

## **Core Strategy**

Webscale utilizes **official Ubuntu-packaged software** for all core infrastructure components. While upstream developers frequently release new "mainline" versions with higher version numbers, Webscale prioritizes the stable versions maintained and vetted by Canonical (the publishers of Ubuntu).

## **The Backporting Mechanism**

The primary reason for staying on a specific Ubuntu package version is the process of **backporting**.

* **Definition:** Backporting is the practice of taking a specific security fix (CVE patch) from a newer version of software and applying it to an older, more stable version.
* **Canonical’s Role:** Canonical’s security team monitors upstream vulnerabilities. When a vulnerability is found in a tool like Nginx, they apply the fix to the version of Nginx currently shipping with the Ubuntu LTS (Long Term Support) release.
* **Result:** The version number of the package remains the same (e.g., 1.18.0), but the security posture is identical to the latest upstream version (e.g., 1.25.x).

## **Technical Comparison: Nginx Security Case Study**

A common customer request is to upgrade to the latest "mainline" version of Nginx to address specific CVEs. The table below illustrates how Webscale/Ubuntu addresses these concerns:

| Feature | Upstream (Mainline) | Ubuntu Package (LTS) |
| :---- | :---- | :---- |
| **Version Number** | Incrementing (e.g., 1.25.x) | Static (e.g., 1.18.x) |
| **Security Fixes** | Included in new releases | **Backported** into existing version |
| **Stability** | Variable (new features may introduce bugs) | High (only security/critical fixes applied) |
| **Vetting** | Community-driven | Rigorously tested by Canonical |

### **Example: CVE-2024-1642**

* **Upstream Fix:** Resolved in Nginx 1.25.2.
* **Ubuntu Fix:** The security patch was backported to the version of Nginx residing in the Ubuntu official repositories.
* **Stance:** A system running the Ubuntu-provided version is as secure against this vulnerability as a system running Nginx 1.25.2, but with significantly higher architectural stability.

## **Key Benefits**

* **Security Validation:** Offloads the intensive task of patch validation and regression testing to Canonical.
* **Consistency:** Ensures that the environment remains stable and predictable, as core library dependencies do not change unexpectedly.
* **Compliance:** Official packages provide a clear audit trail for security compliance and vulnerability management.

## **Verification**

To verify if a specific CVE has been addressed in an "older" Ubuntu package version, users can consult the official Ubuntu Security notices or check the package changelog locally:

```apt-get changelog \<package-name\>```

---

### **Related Links**

* [Ubuntu Security \- CVE Tracking](https://ubuntu.com/security/cves)
* [How Ubuntu keeps your system secure, stable and current](https://ubuntu.com/engage/how-ubuntu-keeps-your-system-secure-stable-and-current)
---
# Content Security Policy Directives
URL: https://docs.webscale.com/docs/reference/content-security-policy/
Description: A list of the available content-security-policy directives for Web Controls



The HTTP `Content-Security-Policy` response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks ([XSS](https://developer.mozilla.org/en-US/docs/Glossary/XSS)).

Webscale’s [`Set Content Security Policy` action for Web Controls](/docs/how-tos/web-controls/csp-create/) allows you to set the following directives. Click the name of each directive for more detailed information.

{{% alert title="Note:" %}}
Any directives not listed here are not fully supported by all browsers. Therefore, they are not available for use in Web Controls.
Most of the information on this page is from [Mozilla’s Developer Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy), visit them for more information.
{{% /alert %}}

## Fetch directives
Fetch directives control locations from which certain resource types may be loaded. These directives also require that you specify a [`<source>`](#source) attribute.

| Option | Description
:--------|----------
**Child source ([`child-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/child-src))** | Defines the valid sources for web workers and nested browsing contexts loaded using elements such as [`<frame>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame) and [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe).
**Connect source ([`connect-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src))** | Restricts the URLs which can be loaded using script interfaces.
**Default source ([`default-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/default-src))** | Serves as a fallback for the other fetch directives.
**Font source ([`font-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/font-src))** | Specifies valid sources for fonts loaded using [`@font-face`](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face).
**Frame source ([`frame-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-src))** | Specifies valid sources for nested browsing contexts loading using elements such as [`<frame>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame) and [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe).
**Image source ([`img-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/img-src))** | Specifies valid sources of images and favicons.
**Media source ([`media-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/media-src))** | Specifies valid sources for loading media using the [`<audio>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio), [`<video>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video) and [`<track>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track) elements.
**Object source ([`object-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/object-src))** | Specifies valid sources for the [`<object>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object), [`<embed>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/embed), and [`<applet>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/applet) elements.
**Script source ([`script-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src))** | Specifies valid sources for JavaScript.
**Style source ([`style-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/style-src))** | Specifies valid sources for CSS stylesheets.

## Document directives
Document directives govern the properties of a document or web worker environment to which a policy applies.

| Option | Description
:--------|----------
**Base URI ([`base-uri`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/base-uri))** | Restricts the URLs which can be used in a document's [`<base>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base) element. Accepts a [`<source>`](#source) attribute.
**Sandbox ([`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox))** |  Enables a sandbox for the requested resource similar to the [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox) attribute. It applies restrictions to a page's actions including preventing popups, preventing the execution of plugins and scripts, and enforcing a same-origin policy. See the [Sandbox values](#sandbox-values) list that follows for the values the sandbox directive accepts.

## Navigation directives
Navigation directives govern to which location a user can navigate to or submit a form to, for example.

| Option | Description
:--------|----------
**Form action ([`form-action`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/form-action))** | restricts the URLs which can be used as the target of a form submissions from a given context.
**Frame ancestors ([`frame-ancestors`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors))** | specifies valid parents that may embed a page using [`<frame>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/frame), [`<iframe>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe), [`<object>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object), [`<embed>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/embed), or [`<applet>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/applet). Accepts a [`<source>`](#source) attribute.

## Other directives

| Option | Description
:--------|----------
**Block all mixed content ([`block-all-mixed-content`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content))** | Prevents loading any assets using HTTP when the page is loaded using HTTPS.
**Upgrade insecure requests ([`upgrade-insecure-requests`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests))** | Instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.

## Source and sandbox values

### Source
The `<source>` attributes you can choose for certain directives:

| Option | Description
:--------|----------
**`self`** | Refers to the origin from which the protected document is being served, including the same URL scheme and port number. You must include the single quotes. Some browsers specifically exclude `blob` and `filesystem` from source directives. Sites needing to allow these content types can specify them using the Data attribute.
**`unsafe-eval`** | Allows the use of `eval()` and similar methods for creating code from strings.
**`unsafe-hashes`** | Allows to enable specific inline [event handlers](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers). If you only need to allow inline event handlers and not inline [`<script>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script) elements or `javascript:` URLs, this is a safer method compared to using the `unsafe-inline` expression.
**`unsafe-inline`** | Allows the use of inline resources, such as inline [`<script>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script) elements, `javascript:` URLs, inline event handlers, and inline [`<style>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/style) elements.
**`none`** | Refers to the empty set; that is, no URLs match.
**`strict-dynamic`** | Specifies that the trust explicitly given to a script present in the markup by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any whitelist or source expressions such as `'self'` or `'unsafe-inline'` will be ignored. See [`script-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) for an example.
**`report-sample`** | Requires a sample of the violating code to be included in the violation report.
**`<host-source>`** | Internet hosts by name or IP address, as well as an optional URL scheme and/or port number. The site's address may include an optional leading wildcard (the asterisk character, `'*'`), and you may use a wildcard (again, `'*'`) as the port number, indicating that all legal ports are valid for the source.<br />This must be manually typed in the **Add Connect source** combo box after selecting a directive, and is not available for `sandbox`, `block-all-mixed-content` or `upgrade-insecure-requests` directives.<br /> Examples:<br /><ul><li>`http://*.example.com`: Matches all attempts to load from any subdomain of example.com using the `http:` URL scheme.</li><li>`mail.example.com:443`: Matches all attempts to access port 443 on mail.example.com.</li><li>`https://store.example.com:` Matches all attempts to access store.example.com using `https:`.</li></ul>
**`<scheme-source>`** | A schema such as 'http:' or 'https:'. The colon is required, single quotes shouldn't be used. You can also specify data schemas (not recommended).<br />This must be manually typed in the **Add Connect source** combo box after selecting a directive, and is not available for `sandbox`, `block-all-mixed-content` or `upgrade-insecure-requests` directives.<br /><ul><li>`data:` Allows [`data:` URIs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) to be used as a content source. Note: This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.</li><li>`mediastream:` Allows [`mediastream:` URIs](https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_API) to be used as a content source.</li><li>`blob:` Allows [`blob:` URIs](https://developer.mozilla.org/en-US/docs/Web/API/Blob) to be used as a content source.</li><li>`filesystem:` Allows [`filesystem:` URIs](https://developer.mozilla.org/en-US/docs/Web/API/FileSystem) to be used as a content source.</li>
**`<hash-algorithm>-<base64-value>`** | A sha256, sha384 or sha512 hash of scripts or styles. The use of this source consists of two portions separated by a dash: the encryption algorithm used to create the hash and the base64-encoded hash of the script or style. When generating the hash, don't include the `<script>` or `<style>` tags and note that capitalization and whitespace matter, including leading or trailing whitespace.<br />See [unsafe inline script](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Unsafe_inline_script) for an example. In CSP 2.0 this applied only to inline scripts. CSP 3.0 allows it in the case of `script-src` for external scripts.<br />This must be manually typed in the **Add Connect source** combo box after selecting a directive, and is not available for `sandbox`, `block-all-mixed-content`, `upgrade-insecure-requests` or `frame-ancestors` directives.
**`add all current application aliases`** | This will add all of the alias URLs you've already specified in your application settings. You can also exclude specific alias URls. Click the trashcan icon next to each one you wish to exclude.
**`dynamically add all aliases`** | This will dynamically add any existing and any future aliases you've specified for your application in the application's settings.

### Sandbox values
The `sandbox` directive accepts the following values:

| Option | Description
:--------|----------
**`allow-downloads-without-user-activation`** | Allows for downloads to occur without a gesture from the user.
**`allow-forms`**| Allows the page to submit forms. If this keyword is not used, this operation is not allowed.
**`allow-modals`** | Allows the page to open modal windows.
**`allow-orientation-lock`** | Allows the page to disable the ability to lock the screen orientation.
**`allow-pointer-lock`** | Allows the page to use the [Pointer Lock API](https://developer.mozilla.org/en-US/docs/WebAPI/Pointer_Lock).
**`allow-popups`** | Allows popups (like from `window.open`, `target="_blank"`, `showModalDialog`). If this keyword is not used, that functionality will silently fail.
**`allow-popups-to-escape-sandbox`** | Allows a sandboxed document to open new windows without forcing the sandboxing flags upon them. This will allow, for example, a third-party advertisement to be safely sandboxed without forcing the same restrictions upon a landing page.
**`allow-presentation`** | Allows embedders to have control over whether an iframe can start a presentation session.
**`allow-same-origin`** | Allows the content to be treated as being from its normal origin. If this keyword is not used, the embedded content is treated as being from a unique origin.
**`allow-scripts`** | Allows the page to run scripts (but not create pop-up windows). If this keyword is not used, this operation is not allowed.
**`allow-storage-access-by-user-activation`** | Lets the resource request access to the parent's storage capabilities with the [Storage Access API](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API).
**`allow-top-navigation`** | Allows the page to navigate (load) content to the top-level browsing context. If this keyword is not used, this operation is not allowed.
**`allow-top-navigation-by-user-activation`**| Lets the resource navigate the top-level browsing context, but only if initiated by a user gesture.

## Further reading

- [How to Configure the Content Security Policy Web Control](/docs/how-tos/web-controls/csp-create/)
- [Content Security Policy (Firefox MDN web docs)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
---
# Introducing HTTP Headers and Status Codes
URL: https://docs.webscale.com/docs/reference/http-headers/
Description: An introduction to HTTP headers and status codes



# Overview

HTTP requests and responses include HTTP headers, which contain additional information that the client and server pass on to each other. Request and response bodies are located at the bottom of the message. Depending on the method, not all requests require bodies. Requests with methods that pertain to fetching resources like `GET`, `HEAD`, `DELETE`, and `OPTIONS` usually don’t need them.

Requests with methods that send data to servers to update them do need bodies. One example is the `POST` method.

## Header directives

Header directives are located after the request and response lines in the form of one or more header fields. There are several types of HTTP headers, each of which attaches more information to the request or response.

## Header types

Following is some of the information that HTTP headers define.

- Caching (as in cache control)
- Client identification (e.g., browser cookies, IP address, user-agent) or anonymity (e.g., VPN or proxy masking, user-agent spoofing)
- Encoding of sent or received information
- Session verification
- Instructions for how the server should handle data
- Age of document being downloaded

## HTTP response status codes

HTTP response status codes indicate whether a specific request successfully completed. They fall into the following numbered categories.

- Informational responses (`100-199`)
- Successful responses (`200-299`)
- Redirection messages (`300-399`)
- Client error messages (`400-499`)
- Server error messages (`500-599`)

## Webscale usage of custom HTTP response status codes

The 467 and 499 HTTP response status codes are custom codes. Webscale uses them to respond to the following situations.

- 467 code: Indicates a client error regarding a CAPTCHA challenge. The incoming request does not accept HTML, so Webscale cannot return a CATCHA challenge page. Instead, it sends this error status response.
- 499: Indicates the client has closed the connection while waiting for the response

# HTTP Cache-Control headers

HTTP Cache-Control headers pertain to requests and responses that relate to cache. The headers consist of instructions that guide how to handle caching. Requests and responses include different types of information.

For example, a request with the `max-age` directive can use the header to request a copy of the resource that is less than an hour old. A response with this directive indicates that the response remains fresh until [*N*] seconds (equivalent to 59 minutes) after the response is generated.

## Webscale caching

If you enable Webscale's optional Dynamic Site Cache, Webscale proxies can cache pages and resources for your application. Thus, your web servers don't have to cache them. By leaving the caching to Webscale, the result is improved performance, reliability, and scalability of your web sites and applications.

Webscale only caches resources according to the site cache rules that you configure and ignores HTTP Cache-Control headers. It does not modify or strip the headers unless you choose to do so by using a Webscale Web Control.

## Webscale CDN caching

Webscale CDN Caching is handled differently if you enable the optional Webscale CDN feature. By default, Webscale CDN does not cache resources. CDN Controls enable you to configure how CDN caches. You can access CDN Controls through the Webscale Control Panel. You can configure Webscale CDN to not ignore Cache-Control header directives

## Request and response discrepancies

If the caching policy of your servers differs from the Webscale site cache rules or Webscale CDN Controls, you might experience unexpected Webscale caching behavior. For example, by setting `Cache-Control: no-store` on your application responses, you are asking caches between your server and the customer's browser to refrain from caching the response. However, the response may still be cached by Webscale CDN and site cache depending on your rules.

Mismatches are also possible between site cache rules and CDN Controls.

# HTTP X-Forwarded-For Headers

HTTP X-Forwarded-For headers are requests for the original IP address of a client that is connecting to a web server through one or more proxies. The header instructions ask for the client's IP address and, possibly, the IP addresses of the proxies.

This header can be used for debugging, statistics, and generating content relevant to a specific location. In Webscale, this IP address functions as the user’s request address. It primarily uses this request address for proxy logs. Webscale can also use it in Web Controls.

## Directives

There are three directives for the X-Forwarded-For header. It must contain <`client`>, which stands for the client IP address.

Optionally, it can contain the <`proxy1`>, <`proxy2`> directives, which represent the IP addresses for the proxies that have handled the message. These directives are located to the right of the <`client`> directive.

When each proxy receives the request, it checks if the request includes the X-Forwarded-For header. If it does, it adds its own IP to the right part of the value of the header. If it doesn't have one, it adds the header with its IP as the only value.

{{% alert title="Important:" %}}
Since any proxy that sees the request can add the X-Forwarded-For header, the header can be spoofed easily.
{{% /alert %}}

### Example

In the following example, three proxies have handled the message before it comes to Webscale.

Client IP address: 192.0.0.11
Proxy IP addresses: 1.2.3.4,  2.2.2.2,  3.3.2.1
Header format: X-Forwarded-For: `192.0.0.11`, `1.2.3.4`,  `2.2.2.2`, `3.3.2.1`

## How Webscale processes X-Forwarded-For headers

The Webscale Trusted Proxies feature enables you to designate proxy IP addresses for providers that you trust. To enable this feature, select address sets and choose to enable Trusted Proxies.

{{% alert title="Note:" %}}
The address sets available for Trusted Proxies are the account address sets. For information on creating and editing address sets, see [Add an address set](/docs/how-tos/security/whitelist/#add-an-address-set).
{{% /alert %}}

Trusted proxies will add the X-Forwarder-For header to messages. If Webscale receives the message from a trusted proxy, it will use the encoded client IP address as the request address. If it receives the message from a proxy that it does not trust, it will strip the header and use the most recent peer address as the request address.

For more information on the Trusted Proxies feature, see [How to Configure Trusted Proxies](/docs/how-tos/advanced/trusted-proxies/).

When you enable Webscale CDN, Webscale automatically adds an address set with the CDN IP addresses.

# Further regarding
- [How to Configure and Flush the Site Cache](/docs/how-tos/advanced/site-cache/)
- [How to Configure Trusted Proxies](/docs/how-tos/advanced/trusted-proxies/)
- [How to Use a CAPTCHA](/docs/how-tos/web-controls/captcha-action/)
---
# Introducing Webscale Account Hierarchies
URL: https://docs.webscale.com/docs/reference/accounts/
Description: An introduction to Webscale account hierarchies



{{% alert title="Note:" %}}Webscale account hierarchies are an advanced feature.{{% /alert %}}

# Overview
Webscale accounts (parent accounts) can optionally be configured with one more sub-accounts to create account hierarchies. This hierarchial relationship naturally matches the structure Webscale Partners use to manage their various eCommerce clients. In concert with [Webscale role-based access](/docs/reference/rbac/), this hierarchy allows Partners to grant a user access to multiple sub-accounts while also being able to limit their access in each account.

## Create a sub-account
In order to create a sub-account, you must have accepted an invitation to the **Entitlement administrator** role, defined in the Webscale-managed account **Root**.
This role is managed by Platform Operations.

This capability is only available through the Webscale API. To successfully create a sub-account, the API request adheres to the following format:
```
POST /v2/accounts
{ "name": <sub-account-name> }
```
where `sub-account-name` is a unique account name. If it is already in use, a `409` status code will be returned and you'll be ask to use a different name.

{{% alert title="Note:" %}}The parent of the sub-account is inferred from the account in which you are authenticated when the API request is made. Setting the parent account directly is not supported. The account you are authenticated into can be found by cross-referencing the `account` attribute from `GET /v2/users/self/authorization` with `GET /v2/accounts`.{{% /alert %}}

Account hierarchies can have unbounded depth, allowing sub-accounts to also serve as parent accounts to yet more sub-accounts.

## Grant access to the account
Sub-accounts will be created with their own **Account owner** role that limits which users are permitted to create roles in the account. By default, no users will be invited to this role unless done so by a Webscale **Account owner administrator**.

By default, when a custom role is created in an account, permission to retrieve the account is automatically added. This means to grant access to a sub-account, you need to invite a user to a role defined in the sub-account, including **Account owner**.

A role, and its permissions, can only be assumed by users that have accepted an invitation and are authenticated into the account in which the role was created. It is also possible to make a role assumable only in sub-accounts, meaning the user must be authenticated into any sub-account of the account in which the role was created in order to assume it.  To do so, select the 'Only sub-accounts' option for 'To what accounts should this role be applied?' when creating a role.
{{< figure src="/images/roles-users/create-role.png" width="50%" alt="New Role Creation" >}}

{{% alert color=warning title="Warning:" %}}Roles applied in sub-accounts will be applied to all sub-accounts of the parent account.{{% /alert %}}

## Remove access to the account
A user can be prevented from accessing a sub-account by revoking their invitations to roles in the sub-account and any roles defined in the parent account that apply to sub-accounts.
---
# Introducing Webscale Role-based Access
URL: https://docs.webscale.com/docs/reference/rbac/
Description: An introduction to Webscale role-based access



# Overview
Webscale role-based access (RBAC) uses the permissions of the roles to which a user has accepted invitations to determine their Webscale API access. **Account owners** can configure roles with granular Webscale API permissions, allowing administrators to deploy to users the least amount of API access needed for the user to complete their task.

This overview will focus on the concepts and mechanisms necessary to understand RBAC.

## Permissions
Roles used for RBAC are configured with permissions. These permissions describe exactly the parts of the API the user can access. Permissions are defined using three pieces of information:
- `method`: For a permission to apply to an incoming API request, the HTTP method on the request and the permission must match. Supported methods include `GET`, `POST`, `PATCH`, `PUT`, `DELETE`.
- `spec`: This contains the collection of API endpoints to which this permission applies. The incoming request's target (e.g. `/v2/applications/abc123`) will be compared to this collection. In addition to matching the HTTP method, if the request's target is contained in the collection, the permission's `effect` is applied.
- `effect`: An effect of `permit` will grant the user access to the requested resource. An effect of `deny` will prevent access and return a `403` status code.

By default, if a relevant permission is not found in any roles to which the user has accepted invitations, the user is denied access to the request target and a `403` status code is returned.

A role may contain any number of permissions and a user may have access to multiple roles in a particular account. In this case, as long as one matching permission with an effect of `permit` exists, the user is granted access.

{{% alert title="Note:" %}}Permissions with an effect of `deny` apply only within the role in which they are defined. As a result, a user with a `permit` permission in one role will be granted access even when another role to which they have access explicitly denies permission to the requested resource.{{% /alert %}}

When defining a permission, wildcards can be used in the `spec` definition to apply to multiple endpoints at once:
  - A single wildcard (`*`) applies to a specific collection of resources or a specific resource but not the sub-resources. For example, `spec: [ '/v2/accounts/*' ]` applies to `/v2/accounts/abc123` and `/v2/accounts/xyz789` but not to `/v2/accounts/abc123/invitations` or `/v2/accounts/xyz789/roles`.
  - A double wildcard (`**`) behaves like a single wildcard but also applies to sub-resources. This means `/v2/applications**` applies to `/v2/applications`, `/v2/appplications/abc123` and `/v2/applications/xyz789/logs`.

## Inviting users
In order to assume a role, a user must be invited and have accepted an invitation to that role. Only **Account owners** are permitted to [invite users](/docs/how-tos/general/user-roles/#invite-a-user-to-an-existing-role) to roles.

Only roles defined in the [account hierarchy](/docs/reference/accounts/) the user is authenticated in are relevant when determining their access to a particular endpoint. If the user has accepted multiple invitations to roles across accounts, roles outside the relevant account hierarchy are ignored.

## RBAC integration
RBAC has been integrated into all [v2 API endpoints](/docs/api/). As a result, searching in the Control Panel for resources like accounts, applications and clusters will only show those resources to which the user has access (`GET /v2/accounts/{id}`), in the account in which the resource resides. Similarly, in order to authenticate into another account, the user must have access to the account in question. Lastly, the types of tasks a user is permitted to run via the tasks API are determined by the following permissions:

| Task                        | Description                                  | Permission |
|-----------------------------|----------------------------------------------|--------------------------|
| `enter_maintenance`           | Put an application into maintenance mode.    | `PATCH /applications/{id}` |
| `exit_maintenance`           | Take an application out of maintenance mode. | `PATCH /applications/{id}` |
| `run-action`                 | Run an application action.                   | `PATCH /applications/{id}` |
| `start`                      | Start an application.                        | `PATCH /applications/{id}` |
| `stop`                       | Stop an application.                         | `PATCH /applications/{id}` |
| `generate-origin-certificate` | Generate a TLS certificate for an application. | `GET /applications/{id}`   |
| `invalidate-cache`            | Flush the application cache.                 | `PUT /applications/{id}`   |

{{% alert title="Note:" %}}In order to run any task, a user must have access to `POST /v2/tasks`.{{% /alert %}}

## Control roles
When an account is created, a set of roles with preconfigured API access are created in the account. These include:
- **Account owner**: This role encapsulates the permissions necessary to manage any role in the account. The account owner is determined during the onboarding process.
- **Editor**: Editors can create, update and delete most resources in the account.
- **Reader**: Readers are limited to read-only access to all resources in the account.

Each control role automatically grants the permissions of the roles below it. That is, a user with
the **Editor** role can also do anything a **Reader** can do, and a user with the
**Account owner** role can also do anything an **Editor** or **Reader** can do.

Once created, these roles are not be maintained by Webscale, allowing the administrator to refine the access users with each role should have. Problems related to API access should first be reported to the account's owner and then to Webscale.

{{% alert title="Note:" %}}Control roles cannot be deleted.{{% /alert %}}

## Administrator-created roles
Administrators also have the option to define unique roles that capture any API access they need to match their use cases. For example:
  - General application edit access vs. specifically configuring CloudEDGE workers on an application.
  - Putting the application into maintenance mode.
  - Running application load tests vs creating application load tests.

{{% alert title="Note:" %}}In order to prevent a user from being locked out of an account in which they have accepted a role, a permission for access to that account is automatically added to any created role. This permission should not be removed.{{% /alert %}}

See [creating roles](/docs/how-tos/general/user-roles/) for more information.
---
# Introducing Webscale service users
URL: https://docs.webscale.com/docs/how-tos/general/service-users/
Description: An introduction to Webscale service users



# Overview
Webscale service users are a special type of Webscale user. Instead of representing a particular person, service users encapsulate a persistent Webscale API access key, useful for completing long-standing tasks, typically in an automated environment like deployment scripts. Service users are scoped to the account and, as a result, can be managed like any other account-level resource.

{{% alert title="Note:" %}}Service users can be granted access to multiple accounts by inviting them to roles in each account.{{% /alert %}}

{{% alert title="Note:" %}}Service users cannot log into the Control Panel.{{% /alert %}}

## Manage service users
Creating, updating and deleting service users can only done directly through the Webscale API.

### Create and update
```
# Creating a service user.
POST /v2/accounts/{account-id}/service-users
{
    "name": ...,
    "description": ...
}

# Updating a service user.
PATCH /v2/accounts/{account-id}/service-users/{user-id}
{
    "name": ...,
    "description": ...
}
```

To create a service user, provide a name and a meaningful description. To make management easier, it is recommended to include the service user's responsibilities in the description. These fields can be updated after creation.

After creating a new service user or updating an existing one, the service user is returned:
```
{
    href: the user's unique API reference,
    name: ...,
    description: ...,
    email: an auto-generated email in the webscalenetworks.com domain,
    account: the account in which the user can be managed,
    access_keys: a collection of access keys granting access to the account,
}
```
It is important to note the service user's `href`, `email` and `access_keys`.
- `href` is used to update the user.
- `email` is used to invite the user to roles and groups.
- `access_keys` grants the user permission to the Webscale API. These access keys do not expire, making them useful for long-standing tasks like creating Webscale custom logs from application servers.

{{% alert color=warning title="Warning:" %}}A service user's access keys cannot be retrieved after they are created.{{% /alert %}}

{{% alert title="Note:" %}}The auto-generated access keys only provide access to the account in which the service user was created.{{% /alert %}}

### Delete
```
DELETE /v2/accounts/{id}/service-users/{id}
```
Deleting a service user requires the service user's ID, which can be retrieved from its `href` attribute.

{{% alert color=warning title="Warning:" %}}Deleting a service user will immediately invalidate all previously issued access keys for the user. {{% /alert %}}

## Invite service users to roles
Service users can be invited to any roles or groups using their email and the [Control Panel](/docs/how-tos/general/user-roles/#invite-a-user-to-an-existing-role).

Once invited, service users can have invitations accepted on their behalf:
```
# List the service user's pending invitations.
GET /v2/users/{user-id}/invitations

# Accept a specific invitation.
PATCH /v2/users/{user-id}/invitations/{invitation-id}
{
    "state": "accepted"
}
```
By default these permissions are granted to **Account editors**.

## Authenticate into different accounts
Although service users are created in a specific account, they can authenticate into other accounts as long as they have accepted a role in that account.

To authenticate into a new account:
```
POST /v2/users/self/authorization
{ "account": <Webscale-account-href> }
```
which returns a JSON web token (JWT) valid for one day.

To generate a persistent access key from this account:
```
POST /v2/users/self/access-keys
{ "type": "bearer" }
```

{{% alert title="Note:" %}}All Webscale API calls require a bearer token. See [Authentication](/docs/api/#authentication) for more information.{{% /alert %}}
---
# Magento 1 EOL Support - FAQ
URL: https://docs.webscale.com/docs/reference/m1eol-support/
Description: Frequently Asked Questions about Webscale's Magento 1 (M1) EOL Support



#### What is M1 Support?

**Webscale M1 Support** is a comprehensive, security-focused SaaS solution for digital commerce merchants planning to remain on Magento 1.x beyond its end-of-life (EOL) in June 2020.

There are two options to **Webscale M1 Support**:
 - **Webscale Cloud M1 Support** for customers whose hosting environment is in the cloud and managed by Webscale (and typically hosted by Webscale as well).
 - **Webscale On-Prem M1 Support** for customers whose hosting environment is not managed by Webscale (maybe hosted in the cloud or in a private data center).

#### Does Webscale support M1 Commerce (formerly known as Enterprise) and M1 Open-source (formerly known as Community)?

Yes! Webscale’s **M1 On-Prem** and **Cloud Support** protects M1 commerce and Open-source customers.

#### What versions within 1.x does Webscale support?

It is required that customers are on the latest 1.x versions and all the patches have been applied for any security patches that Webscale makes available to work.

Webscale’s **M1 On-Prem** and **Cloud Support** protect M1 Commerce on 1.14.x, and M1 Open-source on 1.9.x versions. The latest release of M1 Commerce is 1.14.4.5 and M1 Open-Source is 1.9.4.5.

#### What is the SLA for Webscale M1 Support?

M1 Open-Source customers have a 30 day SLA on availability of patches and M1 Commerce customers have 60-day SLA on availability of patches.

#### Who are our partners for developing security patches?

For M1 Open-Source and M1 Commerce, Webscale partners with specific vendors who are focused on developing patches for Magento 1 versions, as well as our developer partner network who we have contracted with to write Magento 1 security patches.

Patches will be delivered by Webscale support to customers on the [M1 EOL Patches](/docs/reference/m1eol-patches/) page.

#### What does “On Premise M1 Support” mean? Does this refer to technical/support professional services?

Webscale **On Premise (or On Prem) M1 Support** refers to the Webscale SaaS platform subscription and developer support services that support M1 applications after the EOL date. The applications are not hosted by Webscale in the public cloud. The SaaS platform automatically protects from known Magento attacks with custom built-in rulesets, from zero-day vulnerabilities with virtual patching to browser-based attacks with real-time Content Security Policy (CSP) protection. Webscale developer support services for M1 provide regular patches to customer’s development resources to apply and protect against newly discovered vulnerabilities on Magento Open Source and Magento Commerce.

#### How do we identify vulnerabilities?

We will track the Magento community but rely on our partner  to help us identify vulnerabilities. For the most part, Open-Source vulnerabilities are likely also to manifest as Commerce vulnerabilities.

#### What do we need to protect applications to start with?

Webscale will have an M1 base ruleset ready and enabled to protect M1 applications. These will be mandatorily enabled for all Webscale M1 customers. Webscale onboarding/support will write the list of all appropriate rules,  and ensure all M1 Support customers are enabled with these rules.

#### How do we track & test exposure to a new vulnerability?

We will use customer staging environments to reproduce the vulnerability and/or understand its risk and exposure to the application.  No explicit customer agreement is needed at this point.

#### Are the patches applied by Webscale Support?

No. Webscale provides the patches to customers. Customers or their developer team will download and verify the patch in a staging or testing environment before applying the patch to their production system.

#### What is Virtual Patching? How will the process work internally?

A virtual patch is the configuration of a capability in the Webscale platform that limits application exposure to the vulnerability, without making any changes to the application code. The virtual patch is applied outside the application infrastructure, typically in the Webscale data plane. This may be through web controls, ModSecurity rules, access control (allow/block), CSP, or other available configurations.

When a new vulnerability is discovered, Webscale Support will:

 - Determine exposure, if any, to the application due to a new vulnerability.
 - Determine mechanisms to prevent the exposure.
 - Write any rules (web controls, ModSecurity, etc) required to prevent any potential exploits.

This is called _virtual patching_. Once a virtual patch has been applied customers will be notified about the virtual patching.

#### Where can I find the released patches and patch installation instructions?

Further information and instructions for patching can be found on [Magento 1 EOL Patches](/docs/reference/m1eol-patches/).

#### Is there a list of the services in Webscale M1 Support and what is included?

Features | M1 Cloud Support | M1 On-Prem Support
---------|:----------------:|:-----------------:
 Auto-scaling Webscale data plane | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 OWASP top 10 protection | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Self-healing HA Webscale Integration layer | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 L7 Load Balancing | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 WAF: Blacklisting, Whitelisting, Geolocation | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 HTTP/2 | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 HTTPS , TLS 1.2 | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 TLS Offload | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Webscale Control Portal / Real-time Traffic Viewer | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 DDoS Shield Mode | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Mobile Optimization | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 CDN Caching | <i class="fa fa-check" aria-hidden="true"></i> | Optional
 Cache Control | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 3rd party optimization | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Content Optimization | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Dynamic Site Cache | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Performance Monitoring & Alerting | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Virtual Patching  | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Real-time CSP protection | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Magento Security patches  (with SLA) | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 Application Shielding | <i class="fa fa-check" aria-hidden="true"></i> |
 Malware Scanners | <i class="fa fa-check" aria-hidden="true"></i> |
 Intrusion Detection | <i class="fa fa-check" aria-hidden="true"></i> |
 Daily backup | <i class="fa fa-check" aria-hidden="true"></i> |
 Email and Phone support (24 x 7 x 365) | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>
 15 Min Critical Ticket Response time (Max 10 per month) | <i class="fa fa-check" aria-hidden="true"></i> | <i class="fa fa-check" aria-hidden="true"></i>

## Further Reading

- [Magento 1 EOL Patches](/docs/reference/m1eol-patches/)
- [How to Contact Support](/docs/getting-started/support/)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [How to Edit the Whitelist](/docs/how-tos/security/whitelist/)
- [How to Edit the Blacklist](/docs/how-tos/security/blacklist/)
---
# Magento 1 EOL Patches
URL: https://docs.webscale.com/docs/reference/m1eol-patches/
Description: A list of the patches made available to Magento 1 EOL support customers



Patches to fix discovered vulnerabilites in Magento 1 are made available to customers who have a Magento 1 EOL Support plan. A list of these patches is maintained here, including patch date, description, and a link to download the patch. For more information on **Magento 1 EOL Support**, please read the [FAQs](/docs/reference/m1eol-support/).

{{% alert title="Note:" %}}
M1 Commerce patches will be available within 60 days from date mentioned below.
{{% /alert %}}
<!-- A list of the virtual patches that have been applied by Magento 1 EOL Support are also listed here. //-->

| <div style="width:5.7em">Date</div> | ID | Description | Open Source | Commerce
:--------|:------|:---------|:-------:|:-------:|
| Aug 07 2020 | 12 |Improves PCI-DSS compliance by forcing login form to disable autocompletion. |[Download](/m1-patches/webscale-m1-opensource-12.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-12.patch.zip)  |
| Aug 07 2020 | 13 | **<div class="-text-orange">(HIGH)</div>** Re-release of [Adobe's SUPEE-11346](https://helpx.adobe.com/security/products/magento/apsb20-41.html) (originally released on 06/22/2020) for Magento 1.9.4.5. |[Download](/m1-patches/webscale-m1-opensource-13.patch.zip) | |
| Aug 07 2020 | 14 | Prevents parallel logins for the same user account (session attack for backend and frontend).| [Download](/m1-patches/webscale-m1-opensource-14.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-14.patch.zip)  |
| Aug 19 2020 | 15 | Adds new configuration option to enable "secure" marker for all cookies. |[Download](/m1-patches/webscale-m1-opensource-15.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-15.patch.zip)  |
| Aug 28 2020 | 16 |Adds compatibility for PHP 7.3. |[Download](/m1-patches/webscale-m1-opensource-16.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-16.patch.zip)  |
| Aug 28 2020 | 17 | Improves clearing of session data with parallel logins. |[Download](/m1-patches/webscale-m1-opensource-17.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-17.patch.zip)  |
| Oct 01 2020 | 18 | **<div class="-text-red">(CRITICAL)</div>** This patch is based on a backport for [CVE-2020-9690](https://helpx.adobe.com/security/products/magento/apsb20-47.html) of Magento 2. |[Download](/m1-patches/webscale-m1-opensource-18.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-18.patch.zip) |
| Oct 01 2020 | 19 | **<div class="-text-red">(CRITICAL)</div>** Prevents admin users from using soap access w/product attributes and a product to upload and execute executable files to the server. |[Download](/m1-patches/webscale-m1-opensource-19.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-19.patch.zip) |
| Oct 01 2020 | 20 | Prevents admin users with access to `System > Permissions > Variables` from adding config paths for encrypted config fields. |[Download](/m1-patches/webscale-m1-opensource-20.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-20.patch.zip) |
| Oct 29 2020 | 21 | Improves compatibility of 3rd party integrations by flagging cookies as `SameSite=None`. |[Download](/m1-patches/webscale-m1-opensource-21.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-21.patch.zip)  |
| Oct 29 2020 | 22 |**<div class="-text-orange">(HIGH)</div>** Prevents access to the `/downloader` directory. |[Download](/m1-patches/webscale-m1-opensource-22.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-22.patch.zip) |
| Oct 29 2020 | 23 | Replaces the news feed URL in Magento so you receive patch notifications in your admin panel.|[Download](/m1-patches/webscale-m1-opensource-23.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-23.patch.zip) |
| Oct 29 2020 | 24 | Avoids incorrect form keys creating an error log entry. This is an improvement for patch ID 18.|[Download](/m1-patches/webscale-m1-opensource-24.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-24.patch.zip) |
| Oct 29 2020 | 25 | **<div class="-text-red">(CRITICAL)</div>** Fixes an issue whereby an administrator with permission to update product data was able to store an executable file on the server and load it via layout xml.|[Download](/m1-patches/webscale-m1-opensource-25.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-25.patch.zip) |
| Dec 09 2020 | 26 |Improves cookie handling. |[Download](/m1-patches/webscale-m1-opensource-26.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-26.patch.zip)  |
| Dec 09 2020 | 27 |**<div class="-text-orange">(HIGH)</div>** Prevents admin users with permission to import/export data and to create widget instances from loading an executable file via layout xml. |[Download](/m1-patches/webscale-m1-opensource-27.patch.zip)  |[Download](/m1-patches/webscale-m1-commerce-27.patch.zip)  |
| Dec 09 2020 | 28 |**<div class="-text-orange">(HIGH)</div>** Prevents admin users with permission to create products from injecting an executable file on the server via wishlist functionality.|[Download](/m1-patches/webscale-m1-opensource-28.patch.zip)  |[Download](/m1-patches/webscale-m1-commerce-28.patch.zip)  |
| Dec 09 2020 | 29 |**<div class="-text-orange">(HIGH)</div>** Prevents admin users with permission to import/export data and to edit cms pages from injecting an executable file on the server via layout xml. |[Download](/m1-patches/webscale-m1-opensource-29-v2.patch.zip)  |[Download](/m1-patches/webscale-m1-commerce-29-v2.patch.zip)  |
| Dec 09 2020 | 30 |Improves patch 20. |[Download](/m1-patches/webscale-m1-opensource-30.patch.zip)  |[Download](/m1-patches/webscale-m1-commerce-30.patch.zip)  |
| Dec 09 2020 | 31 |Improves patch 21. | [Download](/m1-patches/webscale-m1-opensource-31.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-31.patch.zip)  |
| Dec 09 2020 | 32 |Fixes an issue with patch 23. | [Download](/m1-patches/webscale-m1-opensource-32.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-32.patch.zip)  |
| Jan 21 2021 | 33 |Fixes an issue with patch 31: Cookie secure flag wasn't `boolean` in JavaScript. | [Download](/m1-patches/webscale-m1-opensource-33.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-33.patch.zip)  |
| Jan 21 2021 | 34 |Adds `samesite` setting to PHP based session cookies. | [Download](/m1-patches/webscale-m1-opensource-34.patch.zip) |[Download](/m1-patches/webscale-m1-commerce-34.patch.zip)   |
| Apr 05 2021 | 35 |Fixes a core bug when using prepare data for redirecting. **Note:** This patch is also required for patch 39 to operate properly. | [Download](/m1-patches/webscale-m1-opensource-35.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-35.patch.zip) |
| Apr 05 2021 | 36 |**<div class="-text-orange">(HIGH)</div>** Fixes a bug in Zend Framework's Stream HTTP Wrapper - CVE-2021-3007 | [Download](/m1-patches/webscale-m1-opensource-36.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-36.patch.zip) |
| Apr 05 2021 | 37 |Support for PHP 7.4 and PHP 8. In order to switch to PHP 7.4 or PHP 8 you also have to make sure any custom code and third party extension is compatible with these PHP versions! <div>**Known Issue:** Applying this patch might fail because there are versions of Magento in circulation that use ```\r\n``` line breaks instead of ```\n``` line breaks for certain files.</div> <div>**Option 1:** If you encounter errors when applying the patch, you can use the command line utility dos2unix to correct the line breaks. You can use the following command: ```find . -type f -print0 | xargs -0 dos2unix``` </div> <div>**Option 2:** If you cannot install or use dos2unix, you can also use sed on the command line to correct the line breaks: ```find . -type f -name \*.php -print -exec sed -i '' 's/\r//' {} \;``` </div>  | [Download](/m1-patches/webscale-m1-opensource-37.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-37.patch.zip) |
| Apr 05 2021 | 38 |Changes the content-type in json responses from text/html tot application/json to prevent XSS attacks | [Download](/m1-patches/webscale-m1-opensource-38.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-38.patch.zip) |
| Apr 05 2021 | 39 |The wishlist sharing function has been subject to intensive SPAM abuse. We added a switch to the Magento configuration to disable the sharing functionality. Please note that patch #35 is required for this patch to work properly. Please make sure to configure the setting according to your needs: The behavior of the Wishlist Sharing functionality can be controlled via a new config option in System > Config > Wishlist > Share Options > Enable Sharing | [Download](/m1-patches/webscale-m1-opensource-39.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-39.patch.zip) |
| Apr 05 2021 | 40 |We fixed a vulnerability in the MySQL adapter to prevent SQL injection attacks. CVE-2021-21024 | [Download](/m1-patches/webscale-m1-opensource-40.patch.zip) | [Download](/m1-patches/webscale-m1-commerce-40.patch.zip) |
| May 28 2021 | 41 |Updates Zend_Http_Response to support HTTP/2 | [Download](/m1-patches/webscale-m1-opensource-41.patch) | [Download](/m1-patches/webscale-m1-commerce-41.patch) |
| May 28 2021 | 42 |**<div class="-text-orange">(HIGH)</div>** This patch adds improved security to unserialize() calls to avoid unexpected object creation. Attention: This patch changes almost every unserialize() call throughout the core code to prevent unwanted object creation. It touches many code aspects we're unable to cover with tests. It might also affect functionality you intentionally wanted to create objects via unserialize(). It's therefore crucial to test all your integrations and customizations before you apply it in your live environments! | [Download](/m1-patches/webscale-m1-opensource-42.patch) | [Download](/m1-patches/webscale-m1-commerce-42.patch) |
| May 28 2021 | 43 |**<div class="-text-orange">(HIGH)</div>** We fixed a vulnerability that allowed users with admin access to inject code (RCE) using session manipulation. | [Download](/m1-patches/webscale-m1-opensource-43.patch) | [Download](/m1-patches/webscale-m1-commerce-43.patch) |
| May 28 2021 | 44 |**<div class="-text-orange">(HIGH)</div>** Due to missing sanitation in data flow it was possible for admin users to upload arbitrary executable files to the server. | [Download](/m1-patches/webscale-m1-opensource-44.patch) | [Download](/m1-patches/webscale-m1-commerce-44.patch) |
| May 28 2021 | 45 |**<div class="-text-orange">(HIGH)</div>** Layout XML enabled admin users to execute arbitrary commands via block methods. | [Download](/m1-patches/webscale-m1-opensource-45.patch) | [Download](/m1-patches/webscale-m1-commerce-45.patch) |
| May 28 2021 | 46 |**<div class="-text-orange">(HIGH)</div>** We fixed a vulnerability in Magento's package manager which lead to a RCE via race conditions. | [Download](/m1-patches/webscale-m1-opensource-46.patch) | [Download](/m1-patches/webscale-m1-commerce-46.patch) |
| May 28 2021 | 47 |Zend_Validator wasn't able to validate emails with uptodate TLDs. The list of TLDs has been updated. | [Download](/m1-patches/webscale-m1-opensource-47.patch) | [Download](/m1-patches/webscale-m1-commerce-47.patch) |
| May 28 2021 | 48 |Adds array_key_first() and array_key_last() with a polyfill. | [Download](/m1-patches/webscale-m1-opensource-48.patch) | [Download](/m1-patches/webscale-m1-commerce-48.patch) |
| May 28 2021 | 49 |This fixes a bug introduced with patch #47. Magento uses a copy of Zend's original file with modified paths. While updating the file's content, these modified paths have been replaced with their originals. So Magento wasn't able to find the correct files anymore. | [Download](/m1-patches/webscale-m1-opensource-49.patch) | [Download](/m1-patches/webscale-m1-commerce-49.patch) |
| Aug 9 2021 | 50 |Improves PHP5.6 compatibility for unserialization. Please Note: We do not recommend to use anything older than PHP7.3. There's no support available for older PHP Versions! | [Download](/m1-patches/webscale-m1-opensource-50.patch) | [Download](/m1-patches/webscale-m1-commerce-50.patch) |
| Aug 9 2021 | 51 |Updates phpseclib to version 2.0.32 to fix CVE-2021-30130. | [Download](/m1-patches/webscale-m1-opensource-51.patch) | [Download](/m1-patches/webscale-m1-commerce-51.patch) |
| Aug 9 2021 | 52 |Fixes a persisted XSS vulnerability. | [Download](/m1-patches/webscale-m1-opensource-52.patch) | [Download](/m1-patches/webscale-m1-commerce-52.patch) |
| Aug 9 2021 | 53 |**<div class="-text-red">(CRITICAL)</div>** Restores missing .htaccess files from core automatically. In some Magento installations merchants or developers or agencies accidentally removed .htaccess files from regular core directories and thus exposed security vulnerabilities. To regain protection for these directories we automatically check for deleted .htaccess files and reinstate them in the following locations: <div>```/app/.htaccess /dev/.htaccess /downloader/lib/.htaccess /downloader/Maged/.htaccess  /downloader/template/.htaccess /includes/.htaccess /lib/.htaccess /media/downloadable/.htaccess /media/customer/.htaccess /shell/.htaccess /skin/frontend/rwd/default/scss/.htaccess /var/.htaccess``` </div>| [Download](/m1-patches/webscale-m1-opensource-53.patch) | [Download](/m1-patches/webscale-m1-commerce-53.patch) |
| Aug 9 2021 | 54 |Improving PHP8 compatibility. | [Download](/m1-patches/webscale-m1-opensource-54.patch) | [Download](/m1-patches/webscale-m1-commerce-54.patch) |
| Aug 9 2021 | 55 |Prevent DoS attack via passwords larger than 4k. | [Download](/m1-patches/webscale-m1-opensource-55.patch) | [Download](/m1-patches/webscale-m1-commerce-55.patch) |
| Aug 9 2021 | 56 |**<div class="-text-orange">(HIGH)</div>** An administrator with permission to import/export data and to edit cms pages was able to inject an executable file on the server via layout xml. | [Download](/m1-patches/webscale-m1-opensource-56.patch) | [Download](/m1-patches/webscale-m1-commerce-56.patch) |
| Aug 9 2021 | 57 |**<div class="-text-orange">(HIGH)</div>** Arbitrary command execution in Custom Layout Update via block method. | [Download](/m1-patches/webscale-m1-opensource-57.patch) | [Download](/m1-patches/webscale-m1-commerce-57.patch) |
| Aug 9 2021 | 58 |**<div class="-text-orange">(HIGH)</div>** Arbitrary file delete in customer media allows remote code execution. | [Download](/m1-patches/webscale-m1-opensource-58.patch) | [Download](/m1-patches/webscale-m1-commerce-58.patch) |
| Aug 9 2021 | 59 |This patch adds brute force attack prevention to customer login via Frontend and API as well as admin panel login. If enabled this feature prevents brute force login attacks by disabling the login feature once the failed login attempts limit is reached. With every failed login attempt the login retry time increases. This time is respecting the max_execution_time setting. The failed login attempts counter will be reset if a successful login is detected before it reaches the login attempt limit.  <div>**Customer Login:** To enable this feature, go to ```System > Configuration > Customer Options > Password Options```. The Switch is called 'Enable brute force protection'. The number of failed logins defaults to 10 and can be configured in the field Maximum number of failed attempts. If an account has too many failed logins, an error message will appear. The customer can then send an unlock link via email to the account's address. The email template is called 'Customer Account Unlock Notification'.</div>  <div>**Admin Login:** To enable this feature, go to ```System > Configuration > Admin > Security```. The switch is called 'Enable brute force protection'. The number of failed logins defaults to 10 and can be configured in the field 'Maximum number of failed attempts'. If an account has too many failed logins, an error message will appear. The administrator can then send an unlock link via email to the account's address. The email template is called 'Admin Account Unlock Notification'.</div>  <div>**API:** To enable this feature, go to ```System > Configuration > Magento Core API > General Settings```. The switch is called 'Enable brute force protection'.</div> | [Download](/m1-patches/webscale-m1-opensource-59.patch) | [Download](/m1-patches/webscale-m1-commerce-59.patch) |
| Sep 8 2021 | 60 | Some of our customers are using netz98's magerun tool to maintain their stores. With this patch we add additional compatibility for our last patch #59 features with magerun by adding a reload() Method to the Mage_Customer_Model_Customer. | [Download](/m1-patches/webscale-m1-opensource-60.patch) | [Download](/m1-patches/webscale-m1-commerce-60.patch) |
| Sep 8 2021 | 61 |**<div class="-text-orange">(HIGH)</div>** An administrator with privileges to upload files via DataFlow and to create products was able to execute arbitrary code via the convert profile. The fix applies to the Zend_Db::factory(). | [Download](/m1-patches/webscale-m1-opensource-61.patch) | [Download](/m1-patches/webscale-m1-commerce-61.patch) |
| Nov 4 2021 | 62 | Improves deserialization performance for PHP 5.6.  Please Note: We do not recommend to use anything older than PHP7.3. There's no support available for older PHP Versions! | [Download](/m1-patches/webscale-m1-opensource-62.patch) | [Download](/m1-patches/webscale-m1-commerce-62-2.patch) |
| Nov 4 2021 | 63 | Fixes an issue with brute force protection (patch #59) and requesting reset password link. | [Download](/m1-patches/webscale-m1-opensource-63.patch) | [Download](/m1-patches/webscale-m1-commerce-63-2.patch) |
| Nov 4 2021 | 64 |**<div class="-text-red">(CRITICAL)</div>** An administrator with the right to create or edit CMS pages was able to upload and execute arbitrary code using the wysiwyg editor. | [Download](/m1-patches/webscale-m1-opensource-64.patch) | [Download](/m1-patches/webscale-m1-commerce-64-2.patch) |
| Jan 20 2022 | 65 |**<div class="-text-red">(CRITICAL)</div>** Improves security checks for patch #64 and adds compatibility with symlinked media directories. | [Download](/m1-patches/webscale-m1-opensource-65.patch) | [Download](/m1-patches/webscale-m1-commerce-65.patch)  |
| Jan 20 2022 | 66 | Improves compatibility for third party code and patch #61. | [Download](/m1-patches/webscale-m1-opensource-66.patch) | [Download](/m1-patches/webscale-m1-commerce-66.patch)  |
| Jan 20 2022 | 67 |**<div class="-text-red">(CRITICAL)</div>** Improves compatibility for import file uploads to ./var directory and patch #64. | [Download](/m1-patches/webscale-m1-opensource-67.patch) | [Download](/m1-patches/webscale-m1-commerce-67.patch)  |
| May 12 2022 | 68 |**<div class="-text-red">(CRITICAL)</div>** Fixes to prevent RCE attacks via Varien_Convert_Adapter_Zend_Cache and Mage_Dataflow_Model_Convert_Adapter_Zend_Cache. These classes were not used in Magento core code, thus we decided to remove them completely. We did not see any valid use case to change cache entries via import/export. Attention: If you use any of theses classes in your customization, please be aware that you have to change your custom code in order to stay compatible. | [Download](/m1-patches/webscale-m1-opensource-68.patch) | [Download](/m1-patches/webscale-m1-commerce-68.patch) |
| May 12 2022 | 69 |**<div class="-text-orange">(HIGH)</div>** This patch prevents sending passwords in emails in plain text. Passwords in emails will all be replaced with asterisks. One exception: If an administrator sets a new customer password via the admin panel, in this case you'll now see a note on the input field that this password is sent in plain text. You now have a button to force sending a 'Forgot Password' email via the admin panel. | [Download](/m1-patches/webscale-m1-opensource-69.patch) | [Download](/m1-patches/webscale-m1-commerce-69.patch) |
| May 12 2022 | 70 | This patch fixes a JavaScript issue with Import/Export. | [Download](/m1-patches/webscale-m1-opensource-70.patch) | [Download](/m1-patches/webscale-m1-commerce-70.patch) |
| May 12 2022 | 71 | Fixes a session handling issue for downloadable products, introduced in SUPEE-11314. | [Download](/m1-patches/webscale-m1-opensource-71.patch) | [Download](/m1-patches/webscale-m1-commerce-71.patch) |
| May 19 2022 | 72 | This patch fixes a bug of patch #69 which stopped account confirmation emails to work. With patch #69 we introduced code to redact the customer password from the customer object. This patch fixes a bug that caused the customer account confirmation email to stop working. | [Download](/m1-patches/webscale-m1-opensource-72.patch) | [Download](/m1-patches/webscale-m1-commerce-72.patch) |
| Jul 25 2022 | 73 | This patch fixes an issue with the JS and CSS merge and sets the Content-Type on an educated guess basis. | [Download](/m1-patches/webscale-m1-opensource-73.patch) | [Download](/m1-patches/webscale-m1-commerce-73.patch) |
| Jul 25 2022 | 74 | This patch disables the phar:// protocol to open and/or execute content of phar files (e. g. in the context of including templates). Many of the found vulnerabilities use phar:// files to exploit the system. Forbidding the opening of phar files and preventing the unserialization on them hardens Magento. | [Download](/m1-patches/webscale-m1-opensource-74.patch) | [Download](/m1-patches/webscale-m1-commerce-74.patch) |
| Jul 25 2022 | 75 | This patch improves handling of admin passwords and makes sure to implement PCI security measures. You can now configure admin password strength settings in System > Configuration > Admin > Security > Admin Password Strength. You can set it to any of these values: <div>**Default**</div> <div>Password must contain at least 7 characters. Password must contain at least one number and one letter.</div> <div>**PCI**</div> <div>All of the rules above. Change password every 90 days. No repetition of the last 4 passwords. If password is set by another admin, it is forced to be changed. All admin passwords are forced to be changed on activation.</div> <div>**PCI Advanced**</div> <div>All of the rules above. Password must contain special characters.</div> | [Download](/m1-patches/webscale-m1-opensource-75.patch) | [Download](/m1-patches/webscale-m1-commerce-75.patch) |
| Jul 25 2022 | 76 | **<div class="-text-red">(CRITICAL)</div>** This patch fixes an issue where an admin could use the password forgot feature to escalate their privileges. This patch contains the SQL Formatter which is licensed under the MIT License. | [Download](/m1-patches/webscale-m1-opensource-76.patch) | [Download](/m1-patches/webscale-m1-commerce-76.patch) |
| Jul 25 2022 | 77 | This patch reduces deprecated messages with PHP 8.0/8.1. | [Download](/m1-patches/webscale-m1-opensource-77.patch) | [Download](/m1-patches/webscale-m1-commerce-77.patch) |
| Aug 10 2022 | 78 | Patch (#75) introduced a new feature to harden administrator passwords with forced PCI compliance. Unfortunately this patch interfered with our previously introduced brute force protection (Patch #59). Patch #78 fixes compatibility of admin password PCI compliance (#75) with brute force protection (#59). | [Download](/m1-patches/webscale-m1-opensource-78.patch) | [Download](/m1-patches/webscale-m1-commerce-78.patch) |
| Oct 27 2022 | 79 | This patch fixes a XSS vulnerability in Mage_Dataflow_Model_Convert_Adapter_Http::save() which allows the display of content via $this->getData() on the page using echo(). | [Download](/m1-patches/webscale-m1-opensource-79.patch) | [Download](/m1-patches/webscale-m1-commerce-79.patch) |
| Oct 27 2022 | 80 | This patch replaces rand() with mt_rand() since PHP 7.1 mt_rand() has superseded rand() completely, and rand() was made an alias for mt_rand(). | [Download](/m1-patches/webscale-m1-opensource-80.patch) | [Download](/m1-patches/webscale-m1-commerce-80.patch) |
| Oct 27 2022 | 81 | This patch improves Patch #78: If a user lacks permission to change his password, he is informed about it. This patch fixes the current redirect loop. | [Download](/m1-patches/webscale-m1-opensource-81.patch) | [Download](/m1-patches/webscale-m1-commerce-81.patch) |
| Oct 27 2022 | 82 | This patch improves Patch #76: Read-Query detection is extended by DESCRIBE, TABLES, VALUES, and PREPARE. | [Download](/m1-patches/webscale-m1-opensource-82.patch) | [Download](/m1-patches/webscale-m1-commerce-82.patch) |
| Oct 27 2022 | 83 | This patch adds a message ID to outgoing emails, because especially Google hardened their spam filter for emails without message ID. | [Download](/m1-patches/webscale-m1-opensource-83.patch) | [Download](/m1-patches/webscale-m1-commerce-83.patch) |
| Oct 27 2022 | 84 | This patch provides support for MySQL 8. | [Download](/m1-patches/webscale-m1-opensource-84.patch) | [Download](/m1-patches/webscale-m1-commerce-84.patch) |
| Mar 16 2023 | 85 | This patch improves PHP8 compatibility for Zend_Registry. | [Download](/m1-patches/webscale-m1-opensource-85.patch) | [Download](/m1-patches/webscale-m1-commerce-85.patch) |
| Mar 16 2023 | 86 | This patch improves PHP8 compatibility for report.php. | [Download](/m1-patches/webscale-m1-opensource-86.patch) | [Download](/m1-patches/webscale-m1-commerce-86.patch) |
| Jun 2 2023 | 87 | This patch improves password security by checking if password equals email address for customers and if password equals username or email address for admin users. | [Download](/m1-patches/webscale-m1-opensource-87.patch) | [Download](/m1-patches/webscale-m1-commerce-87.patch) |
| Jun 2 2023 | 88 | This patch improves PHP8 compatibility for the catalog product action attribute form. | [Download](/m1-patches/webscale-m1-opensource-88.patch) | [Download](/m1-patches/webscale-m1-commerce-88.patch) |
| Jun 2 2023 | 89 | This patch improves PHP8 compatibility for Mage_Api_Model_Wsdl_Config_Element. | [Download](/m1-patches/webscale-m1-opensource-89.patch) | [Download](/m1-patches/webscale-m1-commerce-89.patch) |
| Jun 2 2023 | 90 | This patch fixed an login loop issue caused by missing setOrigData(). This patch also hardens bruteforce password protection. | [Download](/m1-patches/webscale-m1-opensource-90.patch) | [Download](/m1-patches/webscale-m1-commerce-90.patch) |
| Jun 2 2023 | 91 | This patch fixes an issue with rejected mails due to incompatible line endings. After upgrading to PHP8, we noticed that all emails were rejected by some mail systems. As of PHP8, the mail() function separates all parts of an email using CRLF instead of LF. However, the Zend_Mail_Transport_Sendmail wrapper class still uses LF as line separator. This resulted in mails being sent with mixed line endings. | [Download](/m1-patches/webscale-m1-opensource-91.patch) | [Download](/m1-patches/webscale-m1-commerce-91.patch) |
| Jun 2 2023 | 92 | This patch prevents javascript execution in email template previews in admin panel. | [Download](/m1-patches/webscale-m1-opensource-92.patch) | [Download](/m1-patches/webscale-m1-commerce-92.patch) |
| Oct 30 2023 | 93 | This patch improves compatibility with PHP 8 and MySQL. Enables ATTR_STRINGIFY_FETCHES in MYSQL-PDO to avoid integer string problems in json encode. | [Download](/m1-patches/webscale-m1-opensource-93.patch) | [Download](/m1-patches/webscale-m1-commerce-93.patch) |
| Oct 30 2023 | 94 | This patch improves MySQL compatibility by adding data type support for unsigned integers. | [Download](/m1-patches/webscale-m1-opensource-94.patch) | [Download](/m1-patches/webscale-m1-commerce-94.patch) |
  | Dec 20 2023 | 95 |**<div class="-text-orange">(HIGH)</div>** This patch improves protection against bruteforce attacks to view guest orders. New protect codes are much longer now. This patch adds a new configuration option to System > Configuration > Sales > General > Block short guest order protect codes to blocks access for guest orders with short protect codes. Ref: CVE-2023-41879 | [Download](/m1-patches/webscale-m1-opensource-95.patch) | [Download](/m1-patches/webscale-m1-commerce-95.patch) |
| Dec 20 2023 | 96 | This patch fixes a typo for patch #94 where we misspelled unsigned with unsinged. | [Download](/m1-patches/webscale-m1-opensource-96.patch) | [Download](/m1-patches/webscale-m1-commerce-96.patch) |
| Feb 15 2024 | 97 | tinyMCE uses iFrame to show its content, which lead to an XSS vulnerability. By sandboxing the iFrame no XSS is possible anymore. <div>**Known Issue:** Applying this patch might fail because there are versions of Magento in circulation that use \r\n line breaks instead of \n line breaks for certain files.</div> <div>**Option 1** If you encounter errors when applying the patch, you can use the command line utility dos2unix to correct the line breaks. You can use the following command: ```find . -type f -print0 | xargs -0 dos2unix``` </div>  <div>**Option 2**  If you cannot install or use dos2unix, you can also use sed on the command line to correct the line breaks: ```find . -type f -name \*.php -print -exec sed -i '' 's/\r//' {} \;``` | [Download](/m1-patches/webscale-m1-opensource-97.patch) | [Download](/m1-patches/webscale-m1-commerce-97.patch) |
| Feb 15 2024 | 98 | Forgot Password feature now uses formkey protection to prevent CSRF attacks.  | [Download](/m1-patches/webscale-m1-opensource-98.patch) | [Download](/m1-patches/webscale-m1-commerce-98.patch) |
| Feb 15 2024 | 99 | This patch improves compatibility for PHP8. In the reports section, total for each column will be calculated with additions. It also covers the name column, which does not contain numbers. The patch will make sure that all value are converted to numbers first. Warning! If e.g. product names start with a number, this will lead to wrong column totals! | [Download](/m1-patches/webscale-m1-opensource-99.patch) | [Download](/m1-patches/webscale-m1-commerce-99.patch) |
| Feb 15 2024 | 100 | This patch improves include file handling in environments with multiple symlinked directories.   | [Download](/m1-patches/webscale-m1-opensource-100.patch) | [Download](/m1-patches/webscale-m1-commerce-100.patch) |
| Jul 30 2024 | 101 | This patch updates phpseclib to version 2.0.47, fixes DoS (denial of service) vulnerability.   | [Download](/m1-patches/webscale-m1-opensource-101.patch) | [Download](/m1-patches/webscale-m1-commerce-101.patch) |
| Jul 30 2024 | 102 | **<div class="-text-orange">(HIGH)</div>** This patch fixes XSS vulnerability in admin panel when uploading files.   | [Download](/m1-patches/webscale-m1-opensource-102.patch) | [Download](/m1-patches/webscale-m1-commerce-102.patch) |
| Jul 30 2024 | 103 | This patch improves PHP 8 compatibility for modules when methods such as call_user_func_array are used.   | [Download](/m1-patches/webscale-m1-opensource-103.patch) | [Download](/m1-patches/webscale-m1-commerce-103.patch) |
| Jul 30 2024 | 104 | This patch improves USPS compatibility.   | [Download](/m1-patches/webscale-m1-opensource-104.patch) | [Download](/m1-patches/webscale-m1-commerce-104.patch) |
| Aug 29 2024 | 105 | This patch adds in-app rate limiting for specific URLs. <div>⚠️ We do highly recommend to use fail2ban for larger shops as it is much faster and provides more configuration. This feature here is meant to protect smaller shops with less sophisticated hosting setups.</div> <div>We do protect the following URLs by default with a limit of 10 requests per 10 seconds:</div> <div>  ``` /customer/account/login ```</div> <div>  ```/sales/guest/form```</div> <div>Rate limits will be tracked in the table ```mageone_ratelimit_log```. A cron job at 1.30 am will remove outdated entries. Further URLs can be added by custom modules. Use your ```config.xm```l file to add new entries to the ```global``` section like so:</div> <div>```<mageone_ratelimit>```</div> <div>```    <custom_identifier>```</div> <div>```        <route>/path/of/url</route>```</div> <div>```        <enabled>true</enabled>```</div> <div>```        <max_queries_in_time_window>10</max_queries_in_time_window>```</div> <div>```        <time_window_in_seconds>10</time_window_in_seconds>```</div> <div>```    </custom_identifier>```</div> <div>```</mageone_ratelimit>```</div> | [Download](/m1-patches/webscale-m1-opensource-105.patch) | [Download](/m1-patches/webscale-m1-commerce-105.patch) |
| Aug 29 2024 | 106 |**<div class="-text-orange">(HIGH)</div>** This patch fixes a file content extraction vulnerability in dataflow.  | [Download](/m1-patches/webscale-m1-opensource-106.patch) | [Download](/m1-patches/webscale-m1-commerce-106.patch) |
| Aug 29 2024 | 107 |**<div class="-text-orange">(HIGH)</div>** This patch fixes a stored XSS vulnerability in dataflow.  | [Download](/m1-patches/webscale-m1-opensource-107.patch) | [Download](/m1-patches/webscale-m1-commerce-107.patch) |
| Aug 29 2024 | 108 | This patch updates UPS integration to work with OAuth2.0. <div>⚠️ Please note that we were unable to get access to the official UPS Test API. This patch therefore is given without warranty.</div> <div> **Please make sure to test it thoroughly in your own setup!**</div>  | [Download](/m1-patches/webscale-m1-opensource-108.patch) | [Download](/m1-patches/webscale-m1-commerce-108.patch) |
| Aug 29 2024 | 109 | This patch fixes a missing translation helper for Patch #105.  | [Download](/m1-patches/webscale-m1-opensource-109.patch) | [Download](/m1-patches/webscale-m1-commerce-109.patch) |
| Aug 29 2024 | 110 | This patch fixes dataflow realpath problems concerning Patch #107.  | [Download](/m1-patches/webscale-m1-opensource-110.patch) | [Download](/m1-patches/webscale-m1-commerce-110.patch) |
| Aug 29 2024 | 111 | This patch improves PHP5.6 compatibility for UPS carrier update from Patch #108.  | [Download](/m1-patches/webscale-m1-opensource-111.patch) | [Download](/m1-patches/webscale-m1-commerce-111.patch) |
| Dec 23 2024 | 112 | This patch fixes the wrong rate limit model instantiation from patch #105.  | [Download](/m1-patches/webscale-m1-opensource-112.patch) | [Download](/m1-patches/webscale-m1-commerce-112.patch) |
| Dec 23 2024 | 113 |**<div class="-text-orange">(HIGH)</div>** This patch fixes a stored XSS in admin system configs CVE-2024-41676.  | [Download](/m1-patches/webscale-m1-opensource-113.patch) | [Download](/m1-patches/webscale-m1-commerce-113.patch) |
| Dec 23 2024 | 114 | This patch improves compatibility with PHP 8 and only closes files that have been opened before.  | [Download](/m1-patches/webscale-m1-opensource-114.patch) | [Download](/m1-patches/webscale-m1-commerce-114.patch) |
| Dec 23 2024 | 115 | This patch fixes the wrong rate limit column name in the cleanup cron in patch #105.  | [Download](/m1-patches/webscale-m1-opensource-115.patch) | [Download](/m1-patches/webscale-m1-commerce-115.patch) |
| Feb 12 2025 | 116 | **<div class="-text-red">(CRITICAL)</div>** This patch fixes an RCE (remote code execution) vulnerability, which allowed a low privileged admin panel user to upload a PHP file and gain full access to database and backend via custom product options file upload.  | [Download](/m1-patches/webscale-m1-opensource-116.patch) | [Download](/m1-patches/webscale-m1-commerce-116.patch) |
| May 21 2025 | 117 | **<div class="-text-orange">(HIGH)</div>** This patch fixes a Cross-Site-Scripting vulnerability in theme configuration fields. This patch will escape HTML content in the 'Welcome' message field. HTML from this field must be removed.  | [Download](/m1-patches/webscale-m1-opensource-117.patch) | [Download](/m1-patches/webscale-m1-commerce-117.patch) |
| Jan 15 2026 | 118 | **<div class="-text-orange">(HIGH)</div>** This patch fixes a XSS vulnerability in Magento's URL processing system. Usage of getBaseUrl() is now protected by solid validation and encoding. Ref: CVE-2025-27400  | [Download](/m1-patches/webscale-m1-opensource-118.patch) | [Download](/m1-patches/webscale-m1-commerce-118.patch) |
| Jul 15 2026 | 119 | **<div class="-text-orange">(HIGH)</div>** This patch hardens Dataflow remote loads (HTTP-CURL) with config toggle and URL allow list (SSRF mitigation).   | [Download](/m1-patches/webscale-m1-opensource-119.patch) | [Download](/m1-patches/webscale-m1-commerce-119.patch) |
| Jul 15 2026 | 120 | **<div class="-text-orange">(HIGH)</div>** This patch hardens XSS protection by properly escaping system configuration field labels and extending the malicious code filter to block all inline event handlers (on* attributes) instead of a hardcoded list.  | [Download](/m1-patches/webscale-m1-opensource-120.patch) | [Download](/m1-patches/webscale-m1-commerce-120.patch) |
| Jul 15 2026 | 121 | This patch fixes an XSS vulnerability in the Dataflow profile process view. Exception output (style attributes, image sources, messages and position info) is now properly escaped.  | [Download](/m1-patches/webscale-m1-opensource-121.patch) | [Download](/m1-patches/webscale-m1-commerce-121.patch) |
| Jul 15 2026 | 122 | **<div class="-text-orange">(HIGH)</div>** This patch strengthens API session ID generation by replacing the weak md5(time() . uniqid()) approach with a cryptographically secure random value via phpseclib. A database migration extends the sessid column to 64 characters to accommodate the longer IDs.  | [Download](/m1-patches/webscale-m1-opensource-122.patch) | [Download](/m1-patches/webscale-m1-commerce-122.patch) |
| Jul 15 2026 | 123 | **<div class="-text-orange">(HIGH)</div>** This patch closes a class of script-breakout XSS vulnerabilities in the admin panel. Introduces escapeJsInHtml() — which JSON-encodes values and escapes `</` sequences — and applies it across ~20 admin templates that previously embedded PHP values directly into inline `<script>` blocks.  | [Download](/m1-patches/webscale-m1-opensource-123.patch) | [Download](/m1-patches/webscale-m1-commerce-123.patch) |


## Severity Categories
**<div class="-text-red">(CRITICAL)</div>** Critical severity issues allow an attacker to read or write arbitrary resources (including but not limited to the file system, registry, network, etc.) on the underlying platform, with the user's full privileges.

**<div class="-text-orange">(HIGH)</div>** High severity vulnerabilities allow an attacker to execute code in the context of, or otherwise impersonate other origins or read cross-origin data. Bugs which would normally be critical severity with unusual mitigating factors may be rated as high severity.

## Patch instructions

{{% alert color="warning" title="Warning" %}}
**Please make a database backup before installing patches live. For best results, use a file versioning tool such as Git to apply the patch.**
{{% /alert %}}

We recommend testing patches in a staging environment first. After testing, the patches can then be installed live using versioning software such as Git. This way the patch can be applied locally (or in the staging environment), then committed and pushed normally. The steps, provided by our partner, are as follows:

1. Upload the local file into the `<Magento_root>` on the server using SFTP, SSH or your normal transport method.
2. Verify the file is in the correct directory.
3. In the command line interface, run the following command according to the patch extension:
    * M1 Open Source: ```$ patch -p1 --ignore-whitespace < /path/to/file```
    * M1 Commerce: ```$ patch -p0 --ignore-whitespace < /path/to/file```
4. For visible changes in the user interface to be reflected, refresh the cache in the Admin under `System > Cache Management`.{{% alert title="Note" %}}  In some cases it will also be necessary to renew the indices.{{% /alert %}}

Patches can also be undone, or reversed, with the `-R` option (or use your version control to remove the changes):
- M1 Open Source: ```$ patch -R -p1 < /path/to/file```
- M1 Commerce: ```$ patch -R -p0 < /path/to/file```

<!-- TODO: add virtual patches or product enhancement section

## Virtual Patches
Patch Date | Description |
:--------|:---------|
| Sep 30 2020 | Lorem ipsum dolor sit amet |

//-->
## Further Reading
- [Magento 1 EOL Support](/docs/reference/m1eol-support/)
- [How to Contact Support](/docs/getting-started/support/)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [How to Edit the Whitelist](/docs/how-tos/security/whitelist/)
- [How to Edit the Blacklist](/docs/how-tos/security/blacklist/)
---
# Glossary
URL: https://docs.webscale.com/docs/reference/glossary/
Description: Canonical definitions for Webscale platform terms, for use in both internal communication and customer-facing docs.


## Platform & products

### Webscale One

**Definition.** Webscale's managed hosting platform for eCommerce. It's the umbrella offering that bundles infrastructure, the Webscale proxy, CDN, and security services into a single managed environment. Customers migrating onto the platform are migrating onto Webscale One.

**Aliases.** None canonical. Avoid "the Webscale platform" in customer-facing materials when you specifically mean Webscale One.

**Example.** *"After your Webscale One environment is provisioned, the migration team will request your domain list and current host paths."*

---

### Webscale Application

**Definition.** A first-class entity in the Webscale Control Panel representing a customer's hosted eCommerce site (Magento, Shopware, etc.). The Application is the configuration container. It holds clusters, Web Controls, CDN settings, and Application Shielding policies.

**Aliases.** "Application" (capital A) when context makes the entity meaning clear. Avoid lowercase "application" when referring to this entity. Reserve lowercase for generic software references.

**Example.** *"On your Application page, click the Actions menu and select Edit."* Avoid: *"Click on your application and edit it,"* which is ambiguous.

**Don't confuse with.** A customer's underlying eCommerce application code (Magento, Shopware), which is the application *stack* or *codebase*.

---

### Stratus

**Definition.** Webscale's managed cloud environment. The hosting tier where customer Applications run on Webscale-provisioned infrastructure rather than on the customer's own AWS account.

**Aliases.** "Stratus cloud," "Stratus environment" are all equivalent. Pick one per document and stay consistent.

**Example.** *"Log files generated by a STRATUS environment are located in the `/log` directory."*

---

### CloudEDGE

**Definition.** Webscale's distributed edge computing platform. CloudEDGE securely executes customer code close to end users at scale, and is the umbrella under which the CDN, Workers, and Handlers features live.

**Example.** *"Webscale CloudEDGE is a distributed computing platform that simplifies global delivery of web applications and services."*

---

### Webscale CDN

**Definition.** Webscale's content delivery network. The caching and acceleration layer that improves website performance by caching assets across geographically distributed edge locations.

**Aliases.** "CloudEDGE CDN" appears in older docs and means the same thing. **Canonical going forward: Webscale CDN.**

**Example.** *"Webscale CDN enhances a website's performance and page load time by caching assets across multiple edge locations."*

---

### CodeDirect

**Definition.** Webscale's container build pipeline that produces deployable images from source code. CodeDirect handles builders, build images, and template substitution for files in the build context.

**Example.** *"Use CodeDirect template substitution to inject secrets into included files at build time."*

---

## Networking & traffic

### Webscale proxy

**Definition.** The Webscale platform's defensive man-in-the-middle layer. All inbound customer traffic flows through the Webscale proxy first, where it can be inspected, filtered, and shaped before reaching the origin. The Webscale proxy is the enforcement point for Web Controls, CSP, and Application Shielding.

**Aliases.** "The proxy" is acceptable in context, but avoid it when egress proxy is also being discussed. Avoid "Webscale's proxy server" (verbose).

**Example.** *"Webscale acts as a defensive man-in-the-middle between your users and your origin. All traffic flows through the Webscale proxy first."*

**Don't confuse with.** *Egress proxy* (a separate product, see below). The Webscale proxy handles **inbound** traffic; the egress proxy handles **outbound**.

---

### Egress proxy

**Definition.** An optional Webscale component that routes a customer's **outbound** HTTP and HTTPS traffic through a fixed, static IP address. Used when an upstream service (payment processor, ERP, supplier API) requires a static-IP allowlist.

**Aliases.** None. Always "egress proxy," never just "proxy" in this context.

**Example.** *"The egress proxy is an optional component within the hosting environment designed to route outbound HTTP and HTTPS traffic through a fixed, static IP address."*

**Don't confuse with.** The Webscale proxy (inbound). When in doubt, lead with the direction word: *inbound Webscale proxy*, *egress proxy*.

---

### Origin

**Definition.** The customer's backend infrastructure that serves the actual application. It's the source of truth that the CDN and Webscale proxy sit in front of. When Webscale CDN gets a cache miss, it forwards the request to origin.

**Example.** *"On a cache miss, Webscale CDN forwards the request to origin and the worker with a request handler runs."*

**Don't confuse with.** *Country of origin*, a Web Control condition that filters by where the request comes from geographically.

---

### Edge

**Definition.** The network location closest to where the end user's browser connects to Webscale. The edge is geographically distributed for fast delivery of static assets and cacheable content. CloudEDGE Workers run at the edge.

**Example.** *"The edge is the network location closest to where the user's browser connects to Webscale."*

---

### SSH Gateway

**Definition.** A Webscale service that gives authorized users SSH access to managed environments without exposing direct SSH ports on customer infrastructure. The gateway acts as a controlled entry point for support, debugging, and operations.

**Aliases.** "Webscale SSH Gateway" in formal contexts.

**Example.** *"Use the SSH Gateway to access your application servers. The gateway gives access without exposing direct SSH on the host."*

---

### Microsite

**Definition.** A standalone, lightweight website that displays in place of an Application, typically used to communicate maintenance, outage status, or to serve user challenge pages, proxy request rejections, and timeout messages.

**Example.** *"A microsite is a standalone website that displays for your Application, for example to inform users that the site is in maintenance mode."*

---

## Compute & deployment

### Cluster

**Definition.** The group of compute resources that runs a customer's Application. A cluster has a defined minimum and maximum size, scales automatically according to its configuration, and can be either VM-based or Kubernetes-based.

**Aliases.** None. The word "cluster" alone should always mean the runtime grouping.

**Example.** *"Define a minimum and maximum desired cluster size that limits these conditions. Find the cluster settings in the Account Settings section of the Webscale Control Panel."*

**Don't confuse with.** *Cluster blueprint* (the configuration template that produces clusters) and *cluster type* (VM vs Kubernetes, a property of the cluster).

---

### Cluster blueprint

**Definition.** The reusable configuration template that defines how a cluster is provisioned: instance counts, scaling rules, logging configuration, and image references. Edited via the Cluster blueprint editor in the Webscale Control Panel.

**Example.** *"The WMA logging service can be configured through the Cluster blueprint editor for VM cluster deployments."*

**Don't confuse with.** A cluster (the running thing) versus the blueprint (the template that produces it).

---

### Autoscaling

**Definition.** Webscale's automatic adjustment of cluster size based on traffic and resource conditions, bounded by a minimum and maximum size set in the cluster blueprint. For Kubernetes clusters, the Helm chart controls pod autoscaling.

**Aliases.** "Auto-scaling" with a hyphen is incorrect. Avoid it; use the closed form.

**Example.** *"Make your changes to the min and max server counts for the cluster, including when the cluster scales out or in."*

---

### CloudEDGE Handlers

**Definition.** Custom JavaScript code, packaged as handler files, that runs in a serverless execution environment at the CDN edge. Handlers are the *code*; they get associated with Web Controls to become Workers at runtime. Handlers are agnostic to the underlying cloud provider.

**Aliases.** "Handlers" alone is acceptable when the CloudEDGE context is established.

**Example.** *"Handlers run your custom JavaScript code in a serverless execution environment that is agnostic to your cloud provider."*

**Don't confuse with.** Workers (see below). The relationship: *handler files* contain code, *handlers* incorporate those files, *workers* are what actually execute when traffic flows through.

---

### CloudEDGE Workers

**Definition.** The runtime execution unit at the CDN edge. A Worker is created when a Handler is associated with a Web Control. The Worker is what actually fires when matching traffic arrives. CloudEDGE Workers are currently available only for Amazon CDN providers.

**Aliases.** "Workers" alone is acceptable when context is set.

**Example.** *"Associating handlers with a control creates a worker that runs the JavaScript function."*

**Don't confuse with.** Handlers (see above). Memorable rule: *Handlers are written, Workers are run.*

---

### Deployment

**Definition.** The act of releasing new code or configuration to a cluster. Webscale Essentials includes deployment commands for Magento and Shopware. Managed deployments can be enabled per cluster so future deployments fire automatically on configuration change.

**Example.** *"All future deployments will be handled automatically when a relevant configuration change is made to the cluster."*

---

## Security & traffic control

### Web Controls

**Definition.** Webscale's rules engine for shaping traffic at the proxy. Web Controls let you configure conditions (country of origin, URL pattern, headers, etc.) and actions (block, rate-limit, run a Worker, modify response, etc.) without touching application code.

**Aliases.** "Web Control" (singular) when referring to a single rule; "Web Controls" (plural) for the system. Avoid "WAF rules" as a synonym. Web Controls can replace WAF rules but they're a broader feature.

**Example.** *"For WAF rules, you can use Web Controls to perform the same functions."*

---

### Application Shielding

**Definition.** Webscale's set of platform-level protections applied to an Application, combining bot defense, rate limiting, CSP enforcement, and Web Controls into a coordinated defensive posture that runs at the Webscale proxy without changes to application code.

**Example.** *"Application Shielding lets you apply protections even when your application stack is hard to change."*

---

### Cloud Bot Manager

**Definition.** Webscale's bot management product, a multi-cloud solution that detects and blocks malicious bot traffic while improving site performance. Bot IP Shield is a feature within Cloud Bot Manager.

**Aliases.** "Bot Manager" alone is acceptable in context. Avoid "the bot product."

**Example.** *"Bot IP Shield is available as part of Cloud Bot Manager or Enterprise Cloud Secure."*

---

### Rate limiting

**Definition.** A defensive Web Controls technique that caps the number of requests from a given source over a time window, raising the cost for attackers (especially in carding scenarios) without blocking legitimate users.

**Example.** *"Rate limiting is one of the most effective defenses against carding because it raises the attacker's cost."*

---

### Content Security Policy (CSP)

**Definition.** A browser security feature that limits which domains a page can load scripts, images, and other resources from. Webscale enforces CSP at the Webscale proxy, which means policies apply uniformly without needing per-page application changes.

**Aliases.** "CSP" should be expanded on first use in customer-facing material.

**Example.** *"Content Security Policy (CSP) is a browser feature that limits which domains your pages can load scripts, images, and other resources from."*

---

### Web Application Firewall (WAF)

**Definition.** A traditional security appliance category that filters HTTP traffic against known attack signatures. Webscale provides equivalent (and often superior) functionality via Web Controls. WAF rule files can still be uploaded for legacy compatibility.

**Aliases.** "WAF" should be expanded on first use externally.

**Example.** *"You can also upload WAF rules, bootstrap, and Geodb files for use by legacy functionality."*

---

## Performance & delivery

### CDN accelerator

**Definition.** An optional add-on subscription that optimizes edge delivery for specific use cases. For example, the Magento Varnish accelerator pairs with the Webscale Varnish Magento module, and HTML Streaming reduces time-to-first-byte for dynamic pages.

**Aliases.** "Accelerator" alone is acceptable in context.

**Example.** *"Subscriptions for CDN accelerators may be set up to optimize edge delivery performance."*

---

### HTML Streaming

**Definition.** A CDN accelerator that streams HTML responses to the browser progressively, with advanced caching and Edge-Side Includes (ESI) support, reducing perceived page load time.

**Example.** *"HTML Streaming is a CDN accelerator that offers fast response times and advanced caching techniques, with Edge-Side Includes support."*

---

### Custom VCL

**Definition.** Varnish Configuration Language code uploaded by the customer that gives complete control over how requests and responses are handled at the CDN's edge servers. Custom VCL is uploaded via the File browser.

**Aliases.** "VCL" should be expanded on first use.

**Example.** *"Custom VCL provides complete control over how requests and responses are handled at the CDN's edge servers."*

---

### PageSpeed

**Definition.** A set of automatic page-optimization features (image compression, asset minification, etc.) configurable through Web Controls. PageSpeed requires CDN to be enabled.

**Example.** *"Web Controls enable you to configure and disable specific PageSpeed features. Without CDN, PageSpeed is disabled."*

---

### Webscale Image Manager

**Definition.** A Webscale CDN feature that automatically converts site images to the WebP format for browsers that support it, with fallback Web Controls for browsers that don't (e.g. older Safari).

**Aliases.** "Image Manager" alone in context.

**Example.** *"For requests that meet the conditions for the Webscale Image Manager Web Controls, the feature converts images to the WebP format."*

---

## Tools & interfaces

### Webscale Control Panel

**Definition.** The web UI where customers manage their Applications, clusters, Web Controls, Workers, Handlers, and account settings. The single canonical name for the customer-facing management interface.

**Aliases.** "Control Panel" alone is acceptable in context. Avoid "Webscale Dashboard" (that's a different concept — the analytics overview within the Control Panel).

**Example.** *"The Webscale Control Panel enables you to manage handlers and workers."*

---

### Traffic Viewer

**Definition.** The Webscale Control Panel feature for analyzing logs (Proxy Logs, Pageview Logs, CDN Logs, Custom Logs). Supports search queries and aggregate views over time.

**Example.** *"The Traffic Viewer is a powerful tool for extracting information from logs and viewing aggregate data and trends over time."*

---

### Webscale CLI

**Definition.** The command-line tool that runs on Webscale-managed servers (`webscale-cli`) for cluster health checks, security operations, log capture, and deployment tasks. Distinct from the Webscale API.

**Example.** *"One of the most common uses of the Webscale CLI is to check the overall health of the cluster: `sudo webscale-cli health`."*

---

### Webscale API

**Definition.** The HTTP API for programmatic interaction with the Webscale platform. Used to automate deployments, purge cache, manage handlers, and integrate with CI/CD pipelines.

**Example.** *"You can use the Webscale API to purge specific items from the cache rather than the entire cache."*

---

### Webscale Monitoring Agent (WMA)

**Definition.** A Webscale-installed agent that captures and publishes text-based logs (web server access logs, error logs, deployment logs) from a customer's environment. Configured via the Cluster blueprint editor.

**Aliases.** "WMA" should be expanded on first use externally.

**Example.** *"Some environments may be set up with the Webscale Monitoring Agent (WMA) to capture and publish text-based logs."*

---

## User & access

### Webscale account

**Definition.** The top-level container in Webscale that owns Applications, billing, and user access. Accounts can have sub-accounts beneath them, forming an account hierarchy. Every API call and Control Panel session is authenticated *into* a specific account.

**Aliases.** "Account" alone is acceptable in context. Avoid "tenant" or "organization." Webscale uses "account."

**Example.** *"To upload a secret to your Webscale account, send a POST request with a valid authorization token to `/v2/secrets`."*

---

### Account hierarchy

**Definition.** The tree structure formed by an account and its sub-accounts. Hierarchies can have unbounded depth. Sub-accounts can themselves serve as parents to further sub-accounts. Used by Partners to grant scoped access to nested customer environments.

**Aliases.** "Account hierarchies" (plural) when referring to the concept. "Sub-account tree" should be avoided.

**Example.** *"Account hierarchies can have unbounded depth, allowing sub-accounts to also serve as parent accounts to yet more sub-accounts."*

---

### Sub-account

**Definition.** An account nested beneath a parent account in an account hierarchy. Sub-accounts have their own users, roles, and resources, but inherit governance from their parent.

**Example.** *"This hierarchy allows Partners to grant a user access to multiple sub-accounts while also being able to limit their access in each account."*

---

### Webscale role (RBAC role)

**Definition.** A configurable bundle of API and Control Panel permissions that a user can be invited to. Webscale uses role-based access control (RBAC). A user's effective access is determined by the roles they've accepted invitations to. Roles can apply to a single account or cascade to its sub-accounts.

**Aliases.** "RBAC role," "API role," "Webscale API role" all refer to the same concept. Pick "Webscale role" externally for clarity.

**Example.** *"A user's access to the Webscale API is determined by the access described by the roles to which they have accepted invitations."*

**Don't confuse with.** *User Role* (capital U, capital R) is a different feature, see below.

---

### User Role

**Definition.** A specific feature within Web Controls that designates groups of users (typically logged-in customers or staff) for use as a condition or action in traffic rules. User Roles power the Webscale Secure Access feature, which protects sections of an Application from the general internet.

**Aliases.** Always two words, both capitalized, which distinguishes from the broader RBAC concept.

**Example.** *"To use this Web Control, first create or edit a User Role for the Web Control to use, and invite at least one user to the role."*

**Don't confuse with.** *Webscale role* (the RBAC concept above). Memorable rule: *Webscale roles control who can administer the platform; User Roles control who can access protected parts of an Application.*

---

### Account owner

**Definition.** The default top-level role created with every Webscale account. The Account owner role limits which users are permitted to create roles within the account, and is the primary administrative role for an account or sub-account.

**Aliases.** "Account owner administrator" appears in some docs and is equivalent.

**Example.** *"Sub-accounts will be created with their own Account owner role that limits which users are permitted to create roles in the account."*

---

### Webscale Secure Access

**Definition.** An optional Web Control action (`restrict-access`) that uses User Roles to protect sections of an Application from the general internet. Checks for a cookie indicating the visitor has been granted one of the specified User Roles before allowing access.

**Example.** *"Webscale Secure Access is an optional Web Control action used to protect parts of your Applications from the general internet."*

---

### Multi-Factor Authentication (MFA)

**Definition.** A second authentication factor (typically a TOTP code or hardware key) required in addition to a password when signing in to Webscale. Configured per user in the User Profile. Account administrators can reset a user's MFA via the Users page.

**Aliases.** "MFA" should be expanded on first use externally. Avoid "2FA," even though it's industry-common; Webscale uses MFA consistently.

**Example.** *"In the User Profile the user can manage their password and their multi-factor authentication settings."*

---

### Access key

**Definition.** A bearer token used to authenticate against the Webscale API. Access keys are tied to a Webscale role and inherit that role's permissions. The `access_keys` permission grants a user the ability to create access keys for the Webscale API.

**Aliases.** "API key" is colloquially used, but **access key** is the canonical Webscale term. Avoid mixing.

**Example.** *"`access_keys` grants the user permission to the Webscale API."*

---

### Webscale Support

**Definition.** The Webscale customer support team and the ticketing system used to reach them. Customers contact Webscale Support to request feature access, report incidents, request infrastructure changes, and escalate technical issues.

**Aliases.** "Support" alone in context. "Webscale support" (lowercase s) is acceptable in narrative prose, but the noun phrase referring to the team/ticket system is **Webscale Support**.

**Example.** *"Contact Webscale Support if database migrations fail or deployment completes but the site shows errors."*

---

## Plans & packaging

### Webscale plan

**Definition.** A customer's subscription tier with Webscale, which determines feature availability, log retention, included services, and SLA. Plans are priced like SaaS, with monthly recurring fees, sometimes with a one-time setup fee. The current plan catalog lives at [webscale.com/plans](https://www.webscale.com/plans/).

**Aliases.** "Webscale subscription" and "Webscale tier" should be avoided. **Webscale plan** is canonical.

**Example.** *"Log retention depends on the Webscale plan you are subscribed to, and any specific log retention periods you are contracted for."*

---

### Cloud Bot Manager

**Definition.** Webscale's standalone bot management plan, a multi-cloud product that detects and blocks malicious bot traffic across any hosted environment. Cloud Bot Manager can be enabled via DNS changes alone and includes Bot IP Shield, Instant Attack Detection, Real-Time Bot Mitigation, and the Bot IP Directory.

**Aliases.** "Bot Manager" alone in context. (Cross-listed in the Security & traffic control category; same product.)

**Example.** *"Cloud Bot Manager can be enabled with just DNS changes to protect any application on any hosted environment."*

---

### Enterprise Cloud Secure

**Definition.** Webscale's enterprise security plan that bundles Cloud Bot Manager, Application Shielding, advanced Web Controls, and Bot IP Shield into a single subscription aimed at large eCommerce customers with comprehensive security needs.

**Aliases.** "Cloud Secure" in context, but full name preferred externally.

**Example.** *"Bot IP Shield is available as part of Cloud Bot Manager or Enterprise Cloud Secure."*

---

### Webscale Essentials

**Definition.** Webscale's foundational deployment toolkit. The entry-level deployment surface that includes basic deployment commands for Magento and Shopware (`essentials-deploy`, `essentials-commands`) and provides the deployment baseline for Webscale One environments.

**Example.** *"Webscale Essentials provides deployment guides and commands for Magento and Shopware applications."*

---

### Webscale M1 Support

**Definition.** A specialized, security-focused support plan for digital commerce merchants who chose to remain on Magento 1.x past its end-of-life in June 2020. Offered in two variants: Webscale Cloud M1 Support (for cloud-hosted environments managed by Webscale) and a self-hosted variant.

**Example.** *"Webscale M1 Support is a comprehensive, security-focused SaaS solution for digital commerce merchants planning to remain on Magento 1.x beyond its end-of-life in June 2020."*

---

### Webscale Shield Mode

**Definition.** An emergency feature, enabled with a single click, that locks all bots out of an Application and validates users to allow only humans through. Used by administrators to buy time during an attack while the underlying pattern is identified and permanently blocked.

**Aliases.** "Webscale Shield" alone in context. Don't confuse with Application Shielding (a broader, always-on protection layer) or Bot IP Shield (a feature within Cloud Bot Manager).

**Example.** *"To get ahead of this problem, the admin can enable Webscale Shield with a single click. Webscale Shield locks all bots out of the application instantly and validates users to only allow humans."*

**Don't confuse with.** *Application Shielding* (continuous protections, see Security category) and *Bot IP Shield* (a Cloud Bot Manager feature). Memorable rule: *Application Shielding is the moat; Webscale Shield Mode is the drawbridge going up.*

---

## Acronym quick reference

A condensed lookup for acronyms used across Webscale docs and customer conversations. Click through to the full entry above where one exists.

| Acronym | Expansion | Notes |
| :---- | :---- | :---- |
| ADC | Application Delivery Controller | Legacy appliance category Webscale replaces. |
| API | Application Programming Interface | Webscale API has its own entry. |
| CDN | Content Delivery Network | See **Webscale CDN**. |
| CLI | Command Line Interface | See **Webscale CLI**. |
| CSP | Content Security Policy | Has full entry. |
| DNS | Domain Name System | Industry-standard. |
| ESI | Edge-Side Includes | A feature of HTML Streaming. |
| HSTS | HTTP Strict Transport Security | Industry-standard. |
| MFA | Multi-Factor Authentication | Has full entry. |
| PCI | Payment Card Industry (DSS) | Compliance context for eCommerce. |
| RBAC | Role-Based Access Control | See **Webscale role**. |
| SSL | Secure Sockets Layer | Use **TLS** in current documentation. |
| TLS | Transport Layer Security | Modern term, preferred over SSL. |
| TTFB | Time To First Byte | Performance metric. |
| TTL | Time To Live | Cache duration. |
| VCL | Varnish Configuration Language | See **Custom VCL**. |
| WAF | Web Application Firewall | Has full entry. |
| WMA | Webscale Monitoring Agent | Has full entry. |
| XSS | Cross-Site Scripting | Attack class. |
---
# Pagespeed Options
URL: https://docs.webscale.com/docs/reference/pagespeed_options/
Description: A list of the default Pagespeed options for Web Controls



By default, Webscale enables the following filters with the default settings as specified by [Add_head](https://www.modpagespeed.com/doc/filter-head-add).

This filter exists primarily to ensure that other filters have a place to insert new tags in the head, or that trigger on the closing-tag of the head to perform some other action.

## Pagespeed Options List

| Option | Description
---------|----------
**[`canonicalize_javascript_libraries`](https://www.modpagespeed.com/doc/filter-canonicalize-js)** | Identifies popular JavaScript libraries and replaces them with ones hosted for free by a JavaScript library hosting service ([Google Hosted Libraries](https://developers.google.com/speed/libraries) by default), which has several benefits, including:<br /><ul><li>Most importantly, first-time site visitors can benefit from browser caching, since they may have visited other sites making use of the same service to obtain the libraries.</li><li>The JavaScript hosting service acts as a content delivery network for the hosted files, reducing load on the server, and improving browser load times.</li></ul>There are no charges for the resulting use of bandwidth by site visitors. Third-party minification tools generally optimize the hosted versions of library code. These optimizations can make use of library-specific annotations or minification settings that aren’t portable to arbitrary JavaScript code, so the libraries benefit from more aggressive optimization than can be provided by PageSpeed.
**[`combine_css`](https://www.modpagespeed.com/doc/filter-css-combine)**| Seeks to reduce the number of HTTP requests made by a browser during page refresh by replacing multiple distinct CSS files with a single CSS file, containing the contents of all of them.<br /> Particularly important in old browsers that were limited to two connections per domain. In addition to reduced overhead for HTTP headers and communications warm-up, this approach works better with TCP/IP slow-start, increasing the effective payload bit-rate through the browser’s network connection.
**[`convert_meta_tags`](https://www.modpagespeed.com/doc/filter-convert-meta-tags)**| Adds a response header that matches each meta tag with an `http-equiv` attribute.<br /> For example, the HTML<br /> `<meta http-eqiv=”Content-Type” content=”text/html; charset=UTF-8″>`<br /> Adds this HTTP header in the response:<br /> `Content-Type: text/html; charset=UTF-8`<br /> The original tag is left unchanged.<br />Certain `http-equiv` meta tags, specifically those that specify content-type, require a browser to reparse the HTML document if they do not match the headers. This avoids reparsing delays by ensuring that the headers match the meta tags.
**[`extend_cache`](https://www.modpagespeed.com/doc/filter-cache-extend)**| Seeks to improve the cacheability of a web page’s resources without compromising the ability of site owners to change the resources and have those changes propagate to users’ browsers.<br />The `extend_cache` filter rewrites the URL references in the HTML page to include a hash of the resource content (if `rewrite_css` is enabled, then image URLs in CSS are also rewritten). Thus if the site owners change the resource content, then the URL for the rewritten resource changes also. Since the old content in the user’s browser cache does not match the new name, the browser does not reference it again.
**[`flatten_css_imports`](https://www.modpagespeed.com/doc/filter-flatten-css-imports)**| Parses linked and inlined CSS and flattens it by replacing all `@import` rules with the contents of the imported file, repeating the process recursively for each imported file.<br /> Works on CSS found in `<style>` blocks and `<link>` references.
**[`inline_css`](https://www.modpagespeed.com/doc/filter-css-inline)**| Reduces the number of requests made by a web page by inserting the contents of small external CSS resources directly into the HTML document.<br /> Reduces the time it takes to display content to the user, especially in older browsers.
**[`inline_import_to_link`](https://www.modpagespeed.com/doc/filter-css-inline-import)**| Converts a `<style>` tag consisting of only @import statements into the corresponding `<link>` tags.<br /> This conversion does not itself result in any significant optimization; rather, its value lies in that it enables optimization of the linked-to CSS files by later filters, in particular the combine_css, rewrite_css, inline_css, and extend_cache filters.
**[`inline_javascript`](https://www.modpagespeed.com/doc/filter-js-inline)**| Reduces the number of requests made by a web page by inserting the contents of small external JavaScript resources directly into the HTML document.<br ?> Reduces the time it takes to display content to the user, especially in older browsers. |
**[`insert_dns_prefetch`](https://www.modpagespeed.com/doc/filter-insert-dns-prefetch)**| Reduces DNS lookup time by providing hints to the browser at the beginning of the HTML, which allows the browser to pre-resolve DNS for resources on the page.<br /> DNS resolution time varies from <1ms for locally cached results to hundreds of milliseconds due to the cascading nature of DNS. This can contribute significantly towards total page load time.
**[`rewrite_css` and `fallback_rewrite_css_urls`](https://www.modpagespeed.com/doc/filter-css-rewrite)**| Parses linked and inline CSS, rewrites the images found and minifies the CSS.<br /> Wroks on CSS found in `<style>` blocks and `<link>` refs.<br /> Many images are referenced from CSS rather than HTML. If `rewrite_images`, `recompress_images`, `recompress_jpeg`, `recompress_png`, `recompress_webp`, `convert_gif_to_png`, `convert_jpeg_to_webp`, `convert_png_to_jpeg`, or `extend_cache` are enabled this filter finds and rewrites those images, saving bytes and extending cache lifetimes.<br />The CSS parser cannot parse some CSS3 or proprietary CSS extensions. If `fallback_rewrite_css_urls` is not enabled, these CSS files are not rewritten at all. If the `fallback_rewrite_css_urls` filter is enabled, a fallback method attempts to rewrite the URLs in the CSS file, even if the CSS cannot be successfully parsed and minified.<br /> Minification can drastically reduce the byte count in standard CSS by stripping all comments and most whitespace and shortening color names. Use this filter to avoid the extra step of minifying CSS by hand when constructing and maintaining a site. This practice reduces the payload size.
**[`rewrite_javascript`](https://www.modpagespeed.com/doc/filter-js-minify)**| Minifies JavaScript code, using an algorithm similar to that in Douglas Crockford’s popular [JSMin program](https://www.crockford.com/jsmin.html).<br /> At present, the filter strips all comments and most whitespace and works only on JavaScript found in `<script>` blocks (either as the target of the src attribute or within the body of the block).<br />Minification can drastically reduce the byte count in common JavaScript code. Use this filter to avoid the extra step of minifying JavaScript code by hand when constructing and maintaining a site. This practice reduces the payload size.
**[`rewrite_style_attributes_with_url`](https://www.modpagespeed.com/doc/filter-rewrite-style-attributes)**| Rewrites CSS inside elements’ style attribute.<br /> Requires `rewrite_css` to also be enabled. See the settings for `rewrite_css` to control CSS minification, image rewriting, image recompression, and cache extension. The `rewrite_style_attributes` filter enables the filter for all style attributes, whereas `rewrite_style_attributes_with_url` enables it only for style attributes that contain the text `url()`, for which you generally want to enable one or more image optimization filters.<br /> `rewrite_style_attributes_with_url` is more efficient because it does not always parse the CSS, but it does not optimize CSS that doesn’t reference any URLs. `rewrite_style_attributes` always parses the CSS and optimize everything possible. Since images are generally the source for most significant improvement and `url()` encloses them, `rewrite_style_attributes_with_url` is a good balance for most uses, while `rewrite_style_attributes` is available for more aggressive optimization.

The two options below specify groups of image optimizations that help to make sure images are high quality and load fast. Please refer to the [Pagespeed site](https://www.modpagespeed.com/doc/reference-image-optimize) for details.

| Option | Description
---------|----------
**`rewrite_images`** | This is a filter group that includes `inline_images`, `recompress_images`, `convert_to_webp_lossless`, and `resize_images`.
**`recompress_images`**  | This is a filter group consisting of `convert_gif_to_png`, `convert_jpeg_to_progressive`, `convert_jpeg_to_webp`, `convert_png_to_jpeg`, `jpeg_subsampling, recompress_jpeg`, `recompress_png`, `recompress_webp`, `strip_image_color_profile`, and `strip_image_meta_data`.

## Further Reading

- [PageSpeed Module](https://developers.google.com/speed/pagespeed/module)
- [Apache PageSpeed](https://www.modpagespeed.com/)
---
# About
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/
Description: The Stratus Stack | Architecture - AWS | High Availability | Environment Types | Access for Developers | Backups and Recovery | Email | Limits | TOS and Magento Requirements

---
# The Webscale STRATUS Stack
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/the-stratus-stack/
Description: Despite the convenient ease of using Webscale Stratus, it may be useful to understand the underlying technology infrastructure of our platform.


{{< figure src="/images/stratus/img/articles/stratus-arch-anim.gif" >}}

Webscale STRATUS is built on top of a micro-services architecture powered by [Kubernetes](https://kubernetes.io "Kubernetes"). Through micro-services, we can assign resources dynamically and provide your environment exactly what it needs. This saves money compared to traditional dedicated hosting solutions where you pay for a limited amount of resources whether you use them or not. The STRATUS stack combined with our dynamic pricing plans means you only pay for what you use it, and it is provided for your store as needed.

## How Your Traffic Requests are Handled

All traffic to your website is directed first to a Cloudfront distribution point. Combined with our custom Web Application Firewall (WAF) rules, your store is protected from distributed-denial-of-service (DDoS) and other malicious attacks which can cripple your storefront. To decrease website response times, cacheable assets, such as images, JavaScript, and CSS files, are stored at Cloudfront edge locations.

For non cacheable requests, load balancers send traffic requests directly to your STRATUS services, starting with Varnish (if enabled). After the services, the requests are then passed to the webserver (Nginx) backend. Nginx receives the request and sends it to the PHP Fast CGI Process Manager (PHP-FPM) where all the heavy lifting works to coordinate any auxiliary services (e.g. Redis, Elasticsearch, Memcache, Sphinx, etc.) and return everything requested back to the requesting web browser.

## Webscale STRATUS Auto-scaling

The biggest limiting factor to scaling a Magento site is the amount of CPU memory available to PHP when page requests are processed. With _Autoscaling_ enabled, Magento code and other needed files are automatically copied across additional PHP-FPM containers. Except for our Resource-Based plans, all STRATUS plans have access to Autoscaling. Once a store is easily [enabled for autoscaling](/docs/reference/stratus/control-panels/autoscaling/ "STRATUS Autoscaling"/), it has nearly limitless resources available to PHP-FPM.

If a high traffic event occurs, more containers come into existence automatically to handle the load.

## MySQL Database

Unlike PHP-FPM, MySQL databases does not scale. MySQL resources are based on your STRATUS plan. Occasionally, sites with poor query or code design can experience bottlenecks in MySQL. However, the majority of Magento stores effectively utilize query caching and are able to sustain high traffic. Your developer can assist with reviewing your store for possible MySQL bottlenecks and optimizing database performance.
---
# Webscale Stratus
URL: https://docs.webscale.com/docs/reference/stratus/
Description: About Webscale Stratus legacy subscriptions


---
# Stratus Architecture — AWS
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/aws-and-stratus/
Description: Currently, Webscale STRATUS is hosted on Amazon Web Services (AWS). The important consideration is that you are not required to do any direct management of the AWS environments used.


The important consideration is that you are not required to do any direct management of the AWS environments used. In other words, you get the full benefit and power of a global cloud services infrastructure without any intervention or configuration. Our STRATUS system works on top of AWS to give you the highest performing technology stack for hosting Magento in a cloud environment.

## Amazon EC2

EC2 is the flagship product of AWS and provides the raw hardware needed to run Webscale STRATUS. The underlying physical nodes for all Webscale STRATUS environments are EC2 instances. The micro-services running your environment run on EC2 instances, as well.

[LEARN ABOUT AWS](https://aws.amazon.com/ec2/ "Amazon EC2")

## Amazon CloudFront

All Webscale STRATUS environments include the Amazon CloudFront Content Delivery Network (CDN). Traffic for all environments route through a CloudFront distribution. Static assets are then cached for improved delivery speed.

MageMojo manages how the CDN manages assets. No configuration on your part is required.

[LEARN ABOUT CLOUDFRONT](https://aws.amazon.com/cloudfront/ "AWS and CloudFront")

## Amazon Simple Email Service

Amazon Simple Email Service (SES) is included with your Webscale STRATUS environment. Domains added to an environment via the [STRATUS URLs List](/docs/reference/stratus/control-panels/domains/urls/ "STRATUS URLs"/) are individually validated with SES. For a domain to be validated requires use of our Route 53 solution. If you wish, you may use your own mail-servers. See [STRATUS Nameservers](/docs/reference/stratus/control-panels/domains/dns/ "STRATUS Nameservers"/) for more on DNS and email configurations.
---
# Stratus High Availability Strategies
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/high-availability-strategies/
Description: High Availability (HA) is the ability of a system to operate continuously without failing for a designated period of time.

## What is High Availability?
By definition, High Availability (HA) is the ability of a system to operate continuously without failing for a designated period of time. HA works to ensure that a system meets an agreed level of operating performance. Data backup and fail-over capabilities play an important role in ensuring that HA systems meet their availability targets. MageMojo currently uses multiple backup strategies to ensure system stability and availability.  In addition to back up concerns, system designers need to pay close attention to the data storage and access technology they use. Highly available systems must be well designed and thoroughly tested before they are used. The good news is, the experienced and knowledgeable MageMojo team has devised a system that will protect your data and grant you the peace of mind that accompanies knowing your site is stable.

## Standard vs Private

|                            |Standard          | Private                                        |
|----------------------------|------------------|------------------------------------------------|
|Database Replication        |Real Time         |Real Time                                       |
|File Replication            |4 hours           |4 hours                                         |
|Access to Read Only Replica |No                |yes                                             |
|Recovery Time               |30 min to 3 hours |1 minute                                        |
|Price                       |Free              |Requires purchase of an additional stratus plan |

## Standard High Availability
Standard High Availability maintains replication in a special replication container that runs using minimal memory as it only needs to write transactions that are already committed. Each of these containers is responsible for writing MySQL data for one stratus instance. This container is not accessible to the customer. Files are then replicated to the standby node every 4 hours.
In the case of a catastrophic failure of an instance, the MageMojo team will first triage the failure and if appropriate, initiate the failover process that stops the appropriate containers for a failed store. The support team then redeploys the store where it mounts these backup filesystems. Because this component is manually done, there can be hours before all stores are failed over.
![ha](/images/stratus/img/articles/hastandard1.png)
![ha](/images/stratus/img/articles/hastandard2.png)

## Private High Availability
Private High Availability utilizes a second Stratus instance which is available as a hot standby. This instance is accessible via the control panel and can also be used as a read-only instance for reporting or other read operations. Files are also replicated to this instance every hour.
In the case of a catastrophic failure of an instance, there is a watcher that monitors the status of all Private High Availability stores. If a store goes into a “Not Ready” state, this watcher will initiate a failover of that store and switch the primary and failover instances. After this switch, the watcher will then repoint CloudFront to standby, bringing the store back online within one minute.
![ha](/images/stratus/img/articles/haactive1.png)
![ha](/images/stratus/img/articles/haactive2.png)
---
# Stratus Environment Types
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/environment-types/
Description: In Webscale STRATUS, you may create two types of environments - Production and Development. These environments are not the same as the production and development modes in Magento 2.


For more on Magento modes, see the [Magento 2 documentation](https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/setup/application-modes.html)

## Production Environment

Your STRATUS account allows for one Production Environment for hosting your live store. Live stores may only be accessed on Production Environments.

For autoscaling plans (as opposed to our Resource-Based plans), [Default Session billing](/docs/reference/stratus/billing/stratus-billing/) can be switched to collect sessions from Google Analytics if preferred.

## Development Environment

Based on your plan, you are entitled to create one or more Development Environments. These Environments can be used for programming, staging, or testing purposes.

> To create a new Environment for an existing STRATUS account, [contact support](/docs/getting-started/support/). Please allow up to 24 hours for the Environment to be created.

When using Development Environments, keep in mind:

* You can not run a store with live domains on a development Environment.
* These Environments are rate limited and cron services are disabled. You may still run cron manually via CLI for testing.
* There are no extra charges for using Development Environments. However, all space used for them is included in the total drive space used for your production STRATUS Environment and may be limited by your STRATUS plan.
* GoogleBot is blocked from accessing Development Environments.
* You may go over your plan allotment for development environments. The system will automatically add $25 to your bill per environment in these cases.
---
# Access for Developers & Authorized Users to Stratus
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/access-for-developers/
Description: Webscale STRATUS requires authorization to ensure only allowed parties have details about your server. Account owners can add others to their account.

Authorized users are generally people for which Webscale STRATUS access is necessary to help you build or maintain your Magento installation. (developers, 3rd party, qa)

> Contacts with access can request changes such as server upgrades/downgrades, software installation, and admin panel access. Users with access may also submit support tickets. <em>They cannot update or see your billing information</em>.

## Developers/Authorized User Access

1. Please have your developer or contact *create* a [Customer Account](https://webscale.com/stratus/magento/customer/account/login/).
	> **Anyone you wish to add to your account *must* have their own Webscale STRATUS account.** Accounts created for access are free.

2. *Log into* your [Customer Account](https://webscale.com/stratus/magento/customer/account/login/).

3. *Go to* the **STRATUS** section. This will launch your Webscale Stratus panel.
<div style="test-align:left">{{< figure src="/images/stratus/img/articles/access-for-devs.png" alt="Screenshot-5" >}}</div>


4. [Choose](/docs/reference/stratus/control-panels/general-panel/info/#switching-stratus-projects-or-environments/) the appropriate Webscale STRATUS project and environment.
  {{< figure src="/images/stratus/img/articles/info-panel-dots.png" alt="Instance names-93" >}}

5. * *Enter* the email address of the person you wish to give access to the selected Webscale STRATUS environment.
	* *Click* the <e>plus sign</em>.
{{< figure src="/images/stratus/img/articles/access-for-developers-2.png" alt="Screenshot-2" >}}
---
# Stratus Email
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/stratus-email/
Description: Using Amazon's Simple Email Service (SES), Webscale STRATUS can deliver your transactional store emails, such as invoice receipts and shipping notifications.

Webscale STRATUS does not include a mail server component for providing POP and IMAP email service. However, using Amazon's Simple Email Service (SES), STRATUS can deliver your transactional store emails, such as invoice receipts, shipping notifications, etc.

For SES to work with your STRATUS environment,

* Your domain must be live and validated with Google Analytics sessions. This allows the cron services to launch and run. Cron services are responsible for handling most email sent by Magento stores.
* Your domain must have its Domain Name Server (DNS) updated to use the [MageMojo Route 53 implementation][2] or the proper SES DNS records have been added to your 3rd party DNS management provider. The necessary DNS records are visible in the Status Control Panel or you may contact Webscale STRATUS Support for assistance.

Since cron services may not work in development or test environments, you may find that emails may not work in these instances, as well.

For sending and receiving other emails for your domain, you must use a 3rd party service. We recommend Google Suite, but there are many other email providers. Other SES accounts will not work with STRATUS.

[LEARN MORE ABOUT AMAZON SES](https://aws.amazon.com/ses/ "Amazon SES")
---
# Stratus Resource Limits
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/limits/
Description: Webscale STRATUS has two types of environments


<strong>Autoscaling</strong> (production) environments & <strong>Development<strong> environments.

Autoscaling environments are the default and recommended production environments for STRATUS.  The autoscaling environments will scale out your website frontend horizontally and automatically in response to surges in traffic.

Autoscaling environments have two types - *Single tenant* and *Multi tenant*.

*Multi tenant* - Starter, Lite, Plus and Select, have all services running across the shared STRATUS platform. The limits in the services are aggregated as a total.

*Single tenant* - Elite, and Custom, have a dedicated ec2 instance for their services except PHP.  PHP is scaled across the shared STRATUS platform.  The limits in the services are not aggregated as a total. The service limits are allowed to use the max resources in the dedicated ec2 instance.

*CPU = Logical Cores, RAM = GB*

## Autoscaling: Multi tenant

|                  |Starter|Lite|Plus|Select|
|------------------|-------|----|----|------|
|Mysql CPU         |4      |8   |8   |10    |
|Mysql RAM         |4      |8   |16  |32    |
|PHP CPU           |Auto   |Auto|Auto|Auto  |
|PHP RAM           |Auto   |Auto|Auto|Auto  |
|Varnish CPU       |1      |1   |1   |1     |
|Varnish RAM       |2      |4   |6   |8     |
|Nginx CPU         |1      |1   |1   |1     |
|Nginx RAM         |1      |2   |3   |4     |
|Cron CPU          |1      |1   |1   |1     |
|Cron RAM          |2      |4   |6   |8     |
|SSH CPU           |1      |1   |1   |1     |
|SSH RAM           |2      |4   |6   |8     |
|Redis Cache CPU   |1      |1   |1   |1     |
|Redis Cache RAM   |1      |2   |4   |4     |
|Redis Sessions CPU|1      |1   |1   |1     |
|Redis Sessions RAM|1      |2   |3   |4     |
|Redis FPC CPU     |1      |1   |1   |1     |
|Redis FPC RAM     |2      |4   |4   |6     |
|ElasticSearch CPU |1      |2   |2   |4     |
|ElasticSearch RAM |2      |4   |6   |8     |
|Memcache CPU      |1      |1   |1   |1     |
|Memcache RAM      |1      |2   |3   |4     |
|Sphinx CPU        |1      |2   |2   |2     |
|Sphinx RAM        |2      |4   |6   |8     |
|RabbitMQ CPU      |1      |1   |1   |1     |
|RabbitMQ RAM      |1      |1   |1   |1     |
|NodeJS CPU        |1      |1   |1   |1     |
|NodeJS RAM        |1      |1   |1   |1     |

## Autoscaling: Single tenant

|                  |Elite|Custom|
|------------------|-----|------|
|Mysql CPU         |12   |24   |
|Mysql RAM         |86   |180   |
|PHP CPU           |Auto |Auto  |
|PHP RAM           |Auto |Auto  |
|Varnish CPU       |12   |24    |
|Varnish RAM       |12   |12    |
|Nginx CPU         |12   |24    |
|Nginx RAM         |12   |12    |
|Cron CPU          |12   |24    |
|Cron RAM          |12   |12    |
|SSH CPU           |12   |24    |
|SSH RAM           |12   |12    |
|Redis Cache CPU   |12   |24    |
|Redis Cache RAM   |12   |12    |
|Redis Sessions CPU|12   |24    |
|Redis Sessions RAM|12   |12    |
|Redis FPC CPU     |12   |24    |
|Redis FPC RAM     |12   |12    |
|ElasticSearch CPU |12   |24    |
|ElasticSearch RAM |12   |20    |
|Memcache CPU      |12   |24    |
|Memcache RAM      |12   |12    |
|Sphinx CPU        |12   |24    |
|Sphinx RAM        |12   |12    |
|RabbitMQ CPU      |1    |1     |
|RabbitMQ RAM      |1    |1     |
|NodeJS CPU        |1    |1     |
|NodeJS RAM        |1    |1     |


## Development environments

Development environments are used for creating development copies.  All Development environments are multi tenant. The limits in these services are aggregated as a total.

*CPU = Logical Cores, RAM = GB*

|                  |Dev |
|------------------|-----------|
|Varnish CPU       |1          |
|Varnish RAM       |2          |
|Nginx CPU         |1          |
|Nginx RAM         |1          |
|Mysql CPU         |4          |
|Mysql RAM	       |4          |
|PHP CPU           |8          |
|PHP RAM           |6          |
|Cron CPU          |1          |
|Cron RAM          |2          |
|SSH CPU           |1          |
|SSH RAM           |2          |
|Redis Cache CPU   |1          |
|Redis Cache RAM   |2          |
|Redis Sessions CPU|1          |
|Redis Sessions RAM|1          |
|Redis FPC CPU     |1          |
|Redis FPC RAM     |1          |
|ElasticSearch CPU |1          |
|ElasticSearch RAM |1          |
|Memcache CPU      |1          |
|Memcache RAM      |1          |
|Sphinx CPU        |1          |
|Sphinx RAM        |2          |
|RabbitMQ CPU      |1          |
|RabbitMQ RAM      |1          |
|NodeJS CPU        |1          |
|NodeJS RAM        |1          |

If you currently own a plan that was discontinued, you may see those limits archived [here](/docs/reference/stratus/storage/limits-legacy/)
---
# Stratus TOS — Magento Requirements
URL: https://docs.webscale.com/docs/reference/stratus/about-webscale-stratus/magento-requirements/
Description: These policies are designed to maximize performance, maintain server stability, and ensure the more reliable hosting configuration in the industry.


To host Magento on STRATUS, installations must adhere to our [Terms of Service](https://magemojo.com/magento/termsofservice) and [Acceptable Use Policy](https://magemojo.com/magento/acceptableuse).

All STRATUS *live* Magento environments must:

* Be in [Production Mode](/docs/reference/stratus/guides/magento-2/set-magento-2-modes/).
* Have all [caches enabled](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/#enabling-caches/).
* Have session storage set to [Redis](/docs/reference/stratus/control-panels/redis-panel/full-page-cache/) or [Memcache](/docs/reference/stratus/control-panels/info/). Sessions cannot be stored in files or the database.
* Install and active the [MageMojo Cron extension](https://github.com/magemojo/m2-ce-cron) on Magento 2 store installs.
* Have indexers set to [Manual Mode](/docs/reference/stratus/guides/magento-1/change-index-mode/) for Magento 1.x and Scheduled for Magento 2.x.
* Ensure that static assets are not stored in the database.
* Enable [Autoscaling](/docs/reference/stratus/control-panels/autoscaling/) on autoscaling plans.
---
# Accessing the Legacy Stratus panel
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/accessing-control-panels/
Description: If you are on a Legacy Stratus plan, you may have access to After a Webscale Stratus environment is created, additional links appear under the customer account on MageMojo.com.


[All access](/docs/reference/stratus/about-webscale-stratus/access-for-developers/ "Developer Access"/) is controlled through customer accounts.

To access Webscale Stratus Admin Panel:

  1. *Log into* [MageMojo](https://magemojo.com/magento/customer/account/login/ "MageMojo"). This is the account you used to purchase STRATUS services or to register as a free user account.
   {{< figure src="/images/stratus/img/articles/access-login-1.png" alt="Login Screen" >}}
  2. *Click* <strong>STRATUS</strong>.
  {{< figure src="/images/stratus/img/articles/access-for-devs.png" alt="STRATUS Link" >}}
  3. *Click* the STRATUS environment you wish to access.
  {{< figure src="/images/stratus/img/articles/access-stratus-list-1.png" alt="STRATUS environment List" >}}
---
# Legacy Panels
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/


---
# Stratus Panel - General
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/general-panel/
Description: Environment Info | Pods | Vitals

---
# Stratus Panel - General > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/general-panel/info/
Description: The initial landing panel when accessing Webscale Stratus is the **Info Panel**.


  * **Account Name** - Assigned to your environment upon initial provisioning. Cannot be changed.
  * [**Stratus Template**](/docs/reference/stratus/control-panels/application-panel/stratus-template/) - Pre-configured Nginx server template. Is assigned based on the version of your software.
  * [**PHP Version**](/docs/reference/stratus/control-panels/php-panel/version/) - Active version of PHP running in the environment.
  * [**Docroot**](/docs/reference/stratus/control-panels/nginx-panel/document-root/) - The root directory in which the Magento store code is located.
  * [**Environment Type**](/docs/reference/stratus/about-webscale-stratus/environment-types/) - Production or Development. Not to be confused with the production and development Magento modes.
  * [**Environment SSL**](/docs/reference/stratus/control-panels/ssl-panel/) - The type of Secure Socket Layer certificate applied to the environment.
  * [**Varnish Status**](/docs/reference/stratus/guides/webscale-stratus/enable-varnish-on-stratus/) - Indicates if Varnish caching is enabled.
  * [**Elasticsearch Status**](/docs/reference/stratus/control-panels/elasticsearch-panel/configuration/) - Indicates if Elasticsearch is running.
  * [**Sphinx Status**](/docs/reference/stratus/control-panels/sphinx-panel/configuration/) - Indicates if Sphinx search is enabled.
  * [**Autoscaling**](/docs/reference/stratus/control-panels/autoscaling/) - Indicates is Autoscaling is enabled.

## Status Indicators

When you come into the **Info Panel**, you will notice a colored circle in the upper left of the sidebar menu, just to the left of your *Environment Name*.

  * A **Green** circle means that all status checks have registered as confirmed.
  * A **Yellow** circle means that one or more status checks need to be tended to, but that the environment is otherwise running.
  * A **Red** circle means that one or more status checks have failed and require immediate attention.

To determine what statuses have failed, see the **Environment Status** area (see below for a further explanation).

## General Info

This panel give you an overview of your Webscale STRATUS environment, and which services are running and/or enabled.

{{< figure src="/images/stratus/img/articles/control-info-1.png" alt="Instance names-92" >}}

## Environment Status Info

This important section shows what "pods" are currently running and illustrates the availability of the pods and all other systems necessary for a fully-functioning Webscale STRATUS environment.

Generally, an environment will have one *service* pod and one *PHP-FPM* pod running. As environments autoscale to meet traffic demands, additional PHP-FPM pods may "spin up" and will be shown in this list.

Other systems that are necessary for *production* environments (i.e., these services may not all be needed for development environments), include:

  * **Domain Verification** — your domain is tested to make sure all DNS records are properly configured. See the [DNS Panel](/docs/reference/stratus/control-panels/domains/dns/ "DNS Panel"/) for more on configuring your domain and [DNS Recommendations](/docs/reference/stratus/guides/dns-and-ssl/stratus-nameservers-and-dns/ "DNS Recommendations Guide"/) for additional guidance.
  * **Health Check** — if Webscale's system finds a condition that prevents the optimized delivery of your site, it will issue a ticket to you and our support staff. For more about Health Check parameters, see the "Health Checks" section of this Knowledge Base (in the sidebar menu).
  * **Terms of Service** — this check confirms that you have met all the Terms of Service conditions, such as Google Analytics connection, in support of your production environment.
  * **Malware** — Webscale regularly scans installations to make sure no apparent malware is present.

You may trigger a re-assessment of the Environment Status information by clicking the small *refresh* icon in the upper right-hand of the panel.

## Personalizing Your Environment

Customized names are helpful if you are managing many sites on Webscale STRATUS. Each project and environment can have its own name. You might label them according to purpose. For example, if you have 3 environments on our Pro plan, where one is the live site and two are for development, you might name the project as the website name and the environments as *Development*, *Staging*, and *Live*.

*Update* the name by clicking the name of the project or environment in the upper left hand menu. Once you update the name, simply *click* **UPDATE** to save your change.

{{< figure src="/images/stratus/img/articles/info-panel-change.png" alt="Instance names-93" >}}

## Switching Webscale STRATUS Projects or Environments

To switch projects or environments:

  1. *Click* the sub-menu (three vertical dots) to the right of your project or environment name at the top of the left sidebar menu.
  2. *Select* the project or environment to which you wish to change in the modal dialogue.
  3. *Click* **CHANGE**.

  {{< figure src="/images/stratus/img/articles/info-panel-dots.png" alt="Instance names-93" >}}
---
# Stratus Panel - General > Pods
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/general-panel/pods/
Description: Webscale STRATUS operates by launching a number of "pods" that run various services for powering a Magento environment.


 In the very least, there is a PHP-FPM pod and a Service pod running for each environment.

As a site auto-scales, copies of the PHP-FPM pod are created to handle the increased traffic.

{{< figure src="/images/stratus/img/articles/pods-1.png" alt="Pods" >}}

Within each pod, are listed any containers with their current status.
---
# Stratus Panel - Account
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/account-panel/
Description: Usage Info | Authorized Users | Alerts

---
# Stratus Panel - Account > Usage
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/account-panel/usage/
Description: This section reports current account usage information for your project. It only reports under your production store since development environments are included per Webscale STRATUS plan allowances.


Please note storage used on your [development environments](/docs/reference/stratus/about-webscale-stratus/environment-types/#development-environment/) is calculated in the total.

* [**Base fee**](/docs/reference/stratus/billing/bill-breakdown/) - A regular monthly payment of a base price depending on the plan.
* [**Sessions**](/docs/reference/stratus/billing/bill-breakdown/)  - Sessions used during the current billing period.
* [**Storage**](/docs/reference/stratus/billing/bill-breakdown/)  - An average of the daily storage space used during the current billing period.
---
# Stratus Panel - Account > Authorized Users
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/account-panel/authorized/
Description: Webscale STRATUS requires authorization to ensure only allowed parties have access to your environments.


* *Enter* the email address of the person you wish to give access to the selected STRATUS environment.
	* *Click* the <e>plus sign</em>.
{{< figure src="/images/stratus/img/articles/access-for-developers-2.png" alt="Screenshot-2" >}}

For further details, please read over [Access for Developers & other Authorized Users](/docs/reference/stratus/about-webscale-stratus/access-for-developers/)
---
# Stratus Panel - Account > Alerts
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/account-panel/alerts/
Description: Receive a notification when any or all plan alert thresholds are reached. Set limits that will give you sufficient warnings to allow proactive steps.


## Plan Limit Alerts

When these limits are reached, you may wish to contact stratus-sales@webscalenetworks.com to analyze your ongoing plan needs.

  > Note: Reaching these thresholds will not interrupt your service.

{{< figure src="/images/stratus/img/articles/alerts-1.png" alt="alerts" >}}

## Plan Overage Alerts

Specify maximum overages allowed for unanticipated traffic and storage usage. You will receive a notification when these limits are reached. When overage are reached, please contact stratus-sales@webscalenetworks.com to analyze usage needs.

{{< figure src="/images/stratus/img/articles/alerts-2.png" alt="alerts" >}}
---
# Stratus Panel - General > DNS Panel
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/domains/dns/
Description: Every site hosted on Webscale STRATUS uses Amazon's Route 53 service. We recommend using our Route 53 solution for all hosted domains. However, it is possible to use 3rd party DNS providers.


See more at [DNS Best Practices](/docs/reference/stratus/guides/dns-and-ssl/stratus-nameservers-and-dns/).

## Viewing your zones

Zones associated with a STRATUS environment can be viewed in your STRATUS Admin panel.

*Select* **Domains->DNS** from the STRATUS sidebar menu.

 {{< figure src="/images/stratus/img/articles/dns-panel-1.png" alt="Create Zone-26" >}}

All zones are created with the following settings:

  * 4 records for validating Amazon SES - 3 CNAME and 1 TXT record.
  * Pointed to the CloudFront distribution CNAME for your STRATUS environment _xxxxxxxx.cloudfront.net_

## Creating a new zone

  1. *Go to* **DNS** in the STRATUS sidebar menu.
  2. *Click* **Add New DNS Zone**.
  3. In the text box to the right, *add* your domain without any prefix. If your site is example.com, then add example.com, but not www.example.com.
  4. *Click* **CREATE** to save the change.

Route 53 will update within a few minutes.

## Edit an existing zone

To add or edit domain records to a zone:

  1. *Go to* **DNS** in the STRATUS sidebar menu.
  2. *Select* your zone from the list.
  {{< figure src="/images/stratus/img/articles/dns-management-3a.png" alt="Edit DNS Zone" >}}
  3. To add an MX record:
    * *Click* **Add MX Record**.
    * *Enter* the "MX Priority" and "MX Domain" values..
    * *Repeat* to add any additional MX Records dneeded.
  4. To add other DNS types:
    * *Select* the **Add Type** from the dropdown at the bottom of the **Edit DNS Zone** panel.
    * *Click* **+**.
    * *Enter* the necessary information for each record.
    * *Repeat* to add any additional records.
  5. To add Google Apps Email records:
    * *Click* **Configure Google Apps Email**.
    * STRATUS will automatically populate the DNS with the necessary Google DNS records for your domain.
  6. To edit any existing record:
    * *Edit* the contents of any records shown.
    * To edit the existing TXT record, *click* **Add TXT Value**.
  7. To delete an existing record:
    * *Click* the **trashcan icon** button to the right of an existing record.
    * *Note* that certain records cannot be deleted. These are protected to ensure proper domain operation.
  7. *Click* **UPDATE** to save and commit your DNS changes.

## Supported record types

STRATUS supports only these record types.

  * A
  * CNAME
  * TXT
  * SRV
  * NS
  * MX
---
# Stratus Panel - Domains
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/domains/
Description: DNS | URLs

---
# Stratus Panel - General > Urls Panel
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/domains/urls/
Description: The URLs list shows all the domains enabled in a Webscale STRATUS environment.


At the server level, this list shows:

  * Domains enabled in the CloudFront distribution
  * Domains listened for in the Nginx configuration
  * Domains for Let's Encrypt and SSL configuration

Any domain *not* shown in this list will not properly work.

## Adding a domain

By default, the domain issued at checkout is included in the Urls list alongside temporary _mojostratus.io_ subdomains. The temporary subdomains are for testing only and MageMojo Support uses them for site migrations.

To add a domain:

  1. *Go to* **Domains->URLs** in the STRATUS sidebar menu.
  2. In the main screen area, *enter* the new domain into the textbox at the bottom of the domain list.
  {{< figure src="/images/stratus/img/articles/url_add-1.png" alt="URL link-67" >}}
  3. *Click* **+** to add the domain to the list.
  4. If you wish to add another domain, *enter* it in the new blank space, then *click* **+**.
  5. *Click* **UPDATE** to confirm your change (domains will not be added until **Update** is clicked).

For any domains, make sure to enter all variants that you need.  If you enter only the root i.e. **mystore.com** also add **www.mystore.com** and so on. _Please note that stratus can only support one document root_

## Removing a domain

  1. *Open* the URLs section of the STRATUS Admin panel.
  2. In the URLs list, *click* the **trashcan icon** next to each domain or URL to remove.
  3. *Click* **UPDATE** at the bottom to confirm.

When the environment goes live, the temporary mojostratus.io domains may be removed. MageMojo Support will remove temporary domains as part of the migration process during the final switchover.

## Domain validation

You may validate your domains here for Google Analytics as described in [our billing guide](/docs/reference/stratus/billing/stratus-billing/)

The left color bar of each domain listed indicates whether the domain has been validated (green) or not (red). For a domain to be validated:

  1. The Domain Name Server (DNS) for the domain is pointed to STRATUS, either via Route 53 nameservers or the proper CloudFront Distribution CNAME,
  2. A Google Analytics code was detected on the domain, and
  3. Our billing system was able to access Google Analytics data for the specific domain.

If any of the above 3 settings are not true, the domain will be marked red. **A red marker is normal when a domain is not live.** Temporary _mojostratus.io_ domains will always be green.


## Domain information

Each URL in the list can be clicked to expand it and provide more information about validation. Items in red indicate an attribute that may need attention.

{{< figure src="/images/stratus/img/articles/validation_expanded1.png" alt="validation-44" >}}

  * **Domain Enabled** - if this domain is enabled.
  * **Domain Live** - if our systems detect that this domain is Live.
  * **GA API Verified** - if Stratus can successfully access your Google Analytics data.
  * **GA Code** - your Google Analytics code will show here if used

Not all fields will be True depending on the domain. A domain that is completely green might also show up with some red status fields.
---
# Stratus Panel - Autoscaling
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/autoscaling/
Description: Auto-scaling is one of the most powerful features of Webscale STRATUS. Auto-scaling keeps a store functioning even during periods of higher than usual traffic.


Configuration of Webscale STRATUS Autoscaling does require some initial configuration. In order to fully benefit from this feature, we recommend that you [contact support for assistance](/docs/getting-started/support/).

## How does autoscaling work?

When high traffic occurs on a Magento store, the code that is processed by PHP — the core Magento code — quickly becomes the bottleneck. Autoscaling resolves these bottlenecks by replicating the PHP code as "containers" across additional physical hardware instances in the AWS cloud.

Certain directories, such as `/media/` and `/var/` are not replicated, as these are generally static files that require greater consistency. These directories are shared across all the PHP containers.

STRATUS Autoscaling only applies to the PHP-FPM code. Except in certain special cases — where MageMojo creates custom autoscaling configurations — STRATUS Autoscaling does not automatically scale MySQL, Redis, Memcache, Elasticsearch, Varnish, or Nginx. Scaling these resources are not normally required.

## Enabling Autoscaling

> **NOTE:** Symlinks must use **absolute paths** in order for autoscaling to work properly.

 1. *Go to* **Autoscaling** in the STRATUS sidebar menu.
    * **Autoscaling with Zero Downtime Deployments Enabled** — *Select* **Autoscaling with Zero Downtime Deployments Enabled** This is also splits a cron container to a separate dedicated services node to reduce load.

    * **Make Code Immutable** — *Select* **Make Code Immutable**. This option makes replicated Magento code in PHP-FPM containers immutable, by that, enhancing security compliance. Autoscaling must be enabled to use this feature.

      Note: Enabling these options will cause a redeploy of services.

	  {{< figure src="/images/stratus/img/articles/autoscalingzdd.jpg" >}}

 	* **Directories to Include** — by default this includes the common directories for Magento 1 or 2 based on the setting chosen under the **Magento > STRATUS Template** panel. Generally, this includes all core code that does not experience changes during normal production operation. These directories will be copied out to additional physical nodes during a scaling event. This should include files and folders that will not be written to during normal operation. Static theme files and code are included by default. If you have extra frameworks like Wordpress or custom scripts, you should include those directories.

		{{< figure src="/images/stratus/img/articles/autoscaling-3.png" >}}

	* **Directories to Exclude** — this section is either empty or contains `pub/media` as a Magento default. Large directories containing extraneous files or code not required by the Production environment should be included in this field. 	Excludes should match the shared folders, especially if you are including part of them in the Includes section. Any large media directories should be excluded. Otherwise scaling will take a very long time as those assets are copied over our network to additional hardware. And you should exclude large subfolders if the parent folder is in the include list. For example, you want to include pub/ for a Magento 2 store, but not include pub/media since it is very large. The exclusion ensures the subfolder is not copied but the rest of the parent folder is copied.

		{{< figure src="/images/stratus/img/articles/autoscaling-4.png" >}}

	* **Shared Mounts** — by default this is `var/` and `media/` (or `pub/media` on Magento 2) directories. Both of these directories experience writes such as cache images or logs during production operation and need to be accessed by all running PHP-FPM containers. Shared mounts are mounted over the network from the home node for your environment. The Magento media folder is the primary folder you need and var, since both folders experience frequent writes (log files or media cache). And most media folders are too large copy out and duplicating media would lead to split brain i.e. a captcha image can be generated on one node but not appear on another if the directory is not shared.

		{{< figure src="/images/stratus/img/articles/autoscaling-5.png" >}}

2. *Click* **DEPLOY CODE** to apply the change. This may result in 1-2 minutes of downtime.

## Updating Code

If Autoscaling is enabled, you can *click* **DEPLOY CODE** to relaunch services and refresh any scaled containers. For a Zero Downtime use the **STRATUS CLI** commands [_zerodowntime.init_ and _zerodowntime.switch_](/docs/reference/stratus/guides/webscale-stratus/stratus-cli/).

> Our general recommendation is to never change production code during high volume traffic/sales except in emergencies.

### Troubleshooting

  * **Some pages are not loading or showing a 404** — check your *includes* to be sure the code is properly copied to additional services.
  * **Weird behavior or PHP errors** — check the PHP error and Magento error logs; there is likely some code that not being included and causing an error. This can also be related to using relative symlinks instead of absolute. You can correct those with the following command:
    ```find ./ -type l -execdir bash -c 'ln -sfn "$(readlink -f "$0")" "$0"' {} \;```
  * **Images are not showing with Autoscaling and Mirasvit SEO** — Under **Stores > Configuration > Mirasvit** in the Magento Admin, *set* **Enable SEO-friendly URLs** for product images to *Disabled*. (``` seo/image/is_enable_image_friendly_url = 0 ```)
  * **CSS is missing or page structure is not rendering correctly** Check the following:
    1. Under **Stores > Configuration > Advanced > Developer > Template Settings** in the Magento Admin, *set* Minify HTML to *No*.
    (``` dev/css/minify_html = 0 ```)
    2. Under **Stores > Configuration > Advanced > Developer**, in Developer mode, set Allow Symlinks to *Yes*.
    (```dev/template/allow_symlink = 1 (true)```)
    3. If you use the module **Aitoc_Compressor**, make sure that you exclude & share the folder pub/static/_aitoc_compressor
    4. If you use the module **Potato_Compressor**, make sure that you exclude & share the folder pub/static/_po_compressor
  * **Environment takes longer than expected to redeploy services** — Make sure there are no large dumps or backups stored in the Magento root directory. Every time php-fpm containers are redeployed, all files, including dumps and backups, are copied and will extend boot time and the ability of your environment to scale on demand quickly.
  * **Crons stop running after deployment** - When using a deployment tool such as Jenkins, Capistrano, Deployer or similar where deployment changes/recreates a new symlink, please note that you should [clear the var/cron directory afterward and empty the cron_schedule table in the database](/docs/reference/stratus/guides/general/debugging-cron-tasks/#restarting-stopped-crons/).

&nbsp;

&nbsp;
---
# Stratus Panel - SSL > Settings
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssl-panel/settings/
Description: The SSL settings panel provides controls for the type of Secure Socket Layer (SSL) certificate applied to a Webscale STRATUS environment.


*Click* **SSL** in the left-hand navigation menu to reveal the SSL panels.

{{< figure src="/images/stratus/img/articles/ssl-settings-1.png" alt="SSL Settings Panel" >}}

The SSL settings panel provides controls for the type of Secure Socket Layer (SSL) certificate applied to a Webscale STRATUS environment. Certificates are applied to the CloudFront distribution for the environment. STRATUS provides five options for installing an SSL certificate:

  1. **Auto** &mdash; attempts to select the best certificate option given the settings available. Defaults to *Let's Encrypt* certificate generation.
  * **Customer Provided Certificate** &mdash; uses a third-party certificate entered into the **Customer Cert** panel.
  * ***mojostratus.io certificate** &mdash; uses the MageMojo wildcard for temporary domains during initial setup or testing or development. **Enabling this will cause any URLs/domains set in the URLs section to stop working if they are not a mojostratus.io subdomain**
  * **Let's Encrypt Certificate** &mdash; for valid domains ([using Route53 nameservers](/docs/reference/stratus/guides/dns-and-ssl/stratus-nameservers-and-dns/)/), will apply a Let's Encrypt certificate, once generated.

The **CloudFront Force SSL** setting will add a forced redirect to HTTPS for all content if set to **On**, the default setting. The redirect will preserve paths (i.e. http://mystore.com/page.html will be directed to https://mystore.com/page.html).

&nbsp;
---
# Stratus Panel - SSL
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssl-panel/
Description: Settings | Customer Cert | Lets Encrypt Cert | CSR

---
# Stratus Panel - SSL > Customer Cert
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssl-panel/customer-cert/
Description: To use a third-party SSL certificate, it must cover every domain listed on the site. If a Stratus environment has multiple domains, the certificate must be a multi-domain or wildcard certificate. Separate certificates for separate domains cannot be installed on the same Webscale Stratus environment.


> It's not unusual for a single Magento environment to be configured for *multistore.* In this configuration, the Magento installation can host multiple storefronts powered by the same Magento backend. Each store would have its own unique domain. If a third-party SSL certificate is desired, it must cover *all* domains used in the multistore environment.

### Installing a certificate

The easiest way to install your certificate is to send a request to [Support](/docs/getting-started/support/) . However, a custom certificate can be installed manually:

  1. *Open* the Webscale STRATUS Admin panel.
  2. *Go to* **SSL > Customer Cert** in the left-hand menu.
  3. *Enter* the **SSL Certficate Private Key**, **SSL Certficate**, and **SSL Intermediate Certficate, CA Bundle, Or Root Certificate** provided by the SSL Certificate issuer.
  4. *Click* **Update** to save the certificate.

The certificate will be pushed to CloudFront, which can take up to 30 minutes to become active.
---
# Stratus Panel - SSL > Let's Encrypt Cert
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssl-panel/lets-encrypt-cert/
Description: Let's Encrypt offers free certificates. On Webscale STRATUS, they can be generated to match your domains.


For a Let's Encrypt certificate to be generated, your domain must be in the [URLs and Domains list](/docs/reference/stratus/control-panels/domains/urls/) and be pointed to the MageMojo Route 53 name servers.

To enable the use of a Let's Encrypt Certificate:

  1. *Go to* **SSL > Settings** in the STRATUS sidebar menu.
  2. *Select* **Let's Encrypt Certificate** in **Environment SSL**.
  3. *Click* **UPDATE** to confirm the change.

A certificate will be generated that matches all the valid domains, creating a multi-domain certificate if needed, and pushed to your CloudFront distribution. The update may take up to 30 minutes.
---
# Stratus Panel - SSL > CSR
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssl-panel/csr/
Description: A CSR or Certificate Signing Request is a block of encoded text that is given to your SSL provider when applying for an SSL Certificate.


To create a CSR:

1. Go to __SSL > CSR__ in the Webscale STRATUS sidebar menu.
2. Choose either existing __New Domain__ or __Existing Domain__
   Make sure you have included all domains listed in the [URL section](/docs/reference/stratus/control-panels/domains/urls/) including www versions.
3. Fill out the remaining sections fully. If you do not have an entry for _Department_, you may enter _N/A_
4. Click CREATE to create the CSR. A private key is created at the same time that you create the CSR and saved in the panel.
   You only need to provide the CSR to your SSL provider. The private key will be used during your SSL installation once ready.

***
__Note__: If you generate a wildcart certificate, make sure you also add the root domain.
_Example - Domain: *.mystore.com, SAN Domain: mystore.com_
***
---
# Stratus Panel - SSH > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssh-panel/info/
Description: Secure Shell (SSH) access is available through a special container on Webscale STRATUS. SSH can be used to manage files and run commands for your environment.



## Configuring for SSH Access

To use SSH on a Webscale STRATUS environment, there are **three** important components:

  1. **Info** — *see below* for viewing the hostname and port number to access Webscale STRATUS via SSH.
  * **[User](/docs/reference/stratus/control-panels/ssh-panel/users/ "Create and edit SSH users"/)** — Users are individually created and managed for security access.
  * **[Whitelist](/docs/reference/stratus/storage/whitelist/ "Manage whitelist IPs"/)** — Additional security for access is managed by allowing only certain IPs to access a Webscale STRATUS environment.

## Info Panel

To view your SSH access information, *go to* **SSH > Info** in the sidebar menu.

  * **Service** — To the right of "SSH," "Running" should be showing. If not, contact MageMojo support.
  * **SSH Host** — This is the *hostname* to use when accessing the STRATUS environment.
  * **SSH Port** — STRATUS uses non-standard port numbers to thwart hackers scanning for normal SSH access ports.

When accessing a Webscale STRATUS environment via SSH, the combination of hostname, port, [user, and password](/docs/reference/stratus/control-panels/ssh-panel/users/ "Create and edit SSH users"/) is required. Additionally, the IP from where the access is attempted must be [whitelisted](/docs/reference/stratus/storage/whitelist/ "Manage whitelist IPs"/).

## Troubleshooting SSH Access

  * If your connection is immediately closed, double check you have [whitelisted](/docs/reference/stratus/storage/whitelist/ "Manage whitelist IPs"/) the correct IP.
  * If you get a password prompt but fail the password check, double check or reset your [password](/docs/reference/stratus/control-panels/ssh-panel/users/ "Create and edit SSH users"/).
  * If you get a key error, check that you have entered the correct public key in the [Authorized Keys](/docs/reference/stratus/control-panels/ssh-panel/users/ "Create and edit SSH users"/) field.
---
# Stratus Panel - SSH
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssh-panel/
Description: Info | Users

---
# Stratus Panel - SSH > Users
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/ssh-panel/users/
Description: Access via SSH begins with creating individual users.


> It is highly recommended that individual SSH user accounts for each person who needs SSH access be created. This allows for access logging and the ability to remove a user if they no longer need access. Sharing SSH access among users can complicate future security issues related to personnel changes. Sharing also reduces accountability.

## Create a SSH User

  1. *Go to* **SSH > Users** in the sidebar menu.

  {{< figure src="/images/stratus/img/articles/ssh-users-1.png" alt="ssh user-41" >}}

  2. *Click* **+ ADD SSH USER**.
    * **Username** — *Enter* the login username. Do not use spaces or other special characters.
	* **Enabled** — *Select* "Yes" if you wish to make the new user active. *Select* "No" to keep them from logging into the STRATUS environment.
	* **Password** — *Enter* a password for the new user. *Click* on **Generate Password** to have the system create a random password. To View the password entered, *click* the **Eye** icon in the password field to reveal the hidden password.
	* **Confirm Password** — The created password must be entered into this field to confirm its accuracy. The **Generate Password** function will automatically fill this field.
	* **Authorized Keys** — If a generated *Authorized Key* is preferred, enter it in this field. See [ssh.com article](https://www.ssh.com/ssh/authorized_keys/ "Visit ssh.com for this and other related articles.") for more on Authorized Keys.
  * **Whitelisted IPs** — Each SSH user created can only be allowed access if their Internet Protocol (IP) address is [whitelisted](/docs/reference/stratus/storage/whitelist/).
  3. *Click* **CREATE**.

Once the user is created, the connection information used for the shell access can be easily copied on the **Edit SSH User** panel.

{{< figure src="/images/stratus/img/articles/ssh-users-2.png" alt="ssh user-41" >}}

## Edit a SSH User

To **edit** a user, *click* the name of the user in the **SSH Users** panel and change the desired information. *Click* **UPDATE** to save changes.

> Note that when viewing the **Edit SSH User** panel, the password field is blank. Any existing password cannot be retrieved once the user is created; if the password is forgotten, a new password must be created and saved. If no entry is made into this password field, other fields may be edited and saved without affecting the existing password.

## Delete a SSH User

To **delete** a user, *click* the name of the user in the **SSH Users** panel. *Click* **DELETE** to remove the user completely from the Status environment as a SSH User.

> Depending on the intent, a user can be *disabled* by changing the **Enabled** field to "No." By disabling the user, their information remains for possible future use.


 [2]:/reference/stratus/storage/whitelist/
---
# Stratus Panel - Access
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/
Description: Controlling Access | Protect Website | Protect URL | Restrict by IP Address | Block Countries | Block Bots

---
# Stratus Panel - Access > Controlling Access
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/controlling-access/
Description: The Webscale STRATUS admin panel provides several tools for controlling external access to a Magento environment. Restricting access may be for development purposes or to keep out unwanted visitors.


> Since your Webscale STRATUS pricing is based on user sessions, it is prudent to restrict users to only those that should be visiting a Magento environment. For example, if a environment is not shipping or selling to customers in Russia, then visitors from Russia can be blocked.

STRATUS provides the following methods for controlling access:

 * **[Protect Website](/docs/reference/stratus/control-panels/access-panel/protect-website/ "Configure website protection"/)** — Set a sitewide username and password in order to access any part of the environment.
 * **[Protect URL](/docs/reference/stratus/control-panels/access-panel/protect-url/ "Configure website URL protection"/)** — Restrict access to specific URL paths in a Magento environment by setting a username and password.
 * **[Restrict By IP Address](/docs/reference/stratus/control-panels/access-panel/restrict-ip/ "Configure IP restrictions"/)** — Restrict access to an environment by allowing or denying specific IP addresses.
 * **[Block Countries](/docs/reference/stratus/control-panels/access-panel/block-countries/ "Configure country blocking"/)** — Block users who are trying to access a Magento environment based on their country location of access.
 * **[Block Bots](/docs/reference/stratus/control-panels/access-panel/block-bots/ "Configure bots blocking"/)** — Block unnecessary "bots" from indexing a Magento environment.
---
# Stratus Panel - Access > Protect Website
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/protect-website/
Description: A standard HTTP Authentication can be added to a website. Visitors will need to enter a username and password to access any part of the website.



## Create Website Protection

To restrict access to the entire website:

 1. *Go to* **Access > Protect Website** in the STRATUS Admin panel left sidebar menu.
   	* *Select* **Enabled**.
   	* **Login** — *Enter* a username.
   	* **Password** — *Enter* a password. To create a random password, *click* **Generate Password**. To view the password, *click* the **Eye Icon** at the right of the password field.
 * *Click* **UPDATE** to save your new login.

 {{< figure src="/images/stratus/img/articles/access-protect-website-1.png" alt="sign in-1" >}}

 > You can only have one HTTP authorization password for a STRATUS environment.

All traffic will be blocked unless the visitor enters the proper username and password.


{{< figure src="/images/stratus/img/articles/access-protect-website-2.png" alt="sign in-2" >}}

## Disable Website Protection

To disable website protection simply *de-select* **Enabled** and *click* **Update**. The login information will be removed from the site.
---
# Stratus Panel - Access > Protect URL
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/protect-url/
Description: A standard HTTP Authentication restriction can be added to your website on a specific URL path. URL protection rules will apply to all domains in the Webscale STRATUS environment.


## Create a Protection Rule

To **create** a path specific authorization rule:

 1. *Go to* **Access > Protect URL** in the STRATUS left sidebar menu.
	{{< figure src="/images/stratus/img/articles/protecturl.png" alt="protect url-75" >}}
 2. *Choose* **+ Add New Rule**
 	* **Label** — *Enter* a name for the rule.
   	* **Restricted URL** — *Enter* the path to be restricted. If the store uses ".html" suffixes, include the suffix with the path. Entering a path ending in a slash ("/") will restrict all files within the directory.
   	* **Login** — *Enter* a login username.
   	* **Password** — *Enter* a password. To create a random password, *click* **Generate Password**. Once saved, passwords cannot be later seen; to view a password before saving, *click* the **Eye Icon** at the right end of the password field.
 3. *Click* **Create** to save your new restriction.

## Edit a Protection Rule

To **edit** an existing rule:

 1. *Choose* desired **rule** from the **rules list**.
	{{< figure src="/images/stratus/img/articles/access-protect-url-1.png" alt="protect url-2" >}}
 2. *Update* the information shown.
 3. *Click* **UPDATE** to save the changes to the rule.

## Delete a Protection Rule

To **delete** an existing rule:

 1. *Choose* desired **rule** from the **rules list**.
 2. *Click* **DELETE** button to remove the rule.
---
# Stratus Panel - Access > Restrict by IP
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/restrict-ip/
Description: By restricting the IP address of visitors, you can allow or deny users according to their Internet address.


## Create a Restriction Rule

To create an IP restriction rule:

 1. *Go to* **Access > Restrict by IP Address** in the STRATUS sidebar menu.
   * *Select* **Redirect Visitor To URL Below If IP Doesn't Match Rules** if you wish to send a restricted user to a special webpage. This page can be on any website; it does not have to be on your STRATUS server. *Enter* the entire URL, including domain.
   {{< figure src="/images/stratus/img/articles/access-restrict-ip-1.png" alt="restrictip-1" >}}
   * *Select* **Deny IP Access To The Website, Except Allowed Below** if you wish to apply a website-wide restriction to all visitors *except* any that are allowed by subsequent rules.
 * *Click* **ADD IP RULE**.
   	* **Label** — Enter a name describing the rule for your use.
   	* **IP Address Or Subnet** — Enter the IP number or subnet to be used for the rule.
   	* **Rule** — *Select* "Allow" or "Deny" to the action preferred for visitors from the IP added to the rule.
 * *Repeat* Step 3 for each rule to be created.
 * *Click* **UPDATE** to apply the rules to the STRATUS environment.

## Restriction Scenarios

To illustrate how to use this feature, the following are example scenarios.

### Restrict for a development site

The strategy is to *select* **Deny IP Access To The Website, Except Allowed Below**, thereby restricting *all* visitors. Then, create rules that will specifically allow the IP addresses for developers or offices that are allowed to access the environment.

  {{< figure src="/images/stratus/img/articles/restrictip.png" alt="restrictip-40" >}}

### Restrict only certain IPs

The IP Address section can be used to block malicious or unwanted IPs as *basic* protection. In this example, all visitors are allowed, but certain IP numbers are denied access.

  {{< figure src="/images/stratus/img/articles/blockipsnew.png" alt="blockips-13" >}}
---
# Stratus Panel - Access > Block Countries
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/block-countries/
Description: Countries can be blocked from accessing a Webscale STRATUS environment based on the geographic location of their IP number. All traffic is stopped before it reaches your Webscale STRATUS environment.


 The location of the accessing IP is determined by lookups in databases that match IP numbers with known locations of IP address blocks. GeoIP is not perfect but it will block most of the traffic from a given country.

Country blocks, unlike the other access restrictions in the **Access** section, apply their block *directly* to your CloudFront distribution. All traffic is stopped before it reaches your STRATUS environment.

## Create Country Blocks

To create blocks:

 1. *Go to* **Access > Block Countries** in the STRATUS left sidebar menu.
   * *Click* **Allow Access For All Countries** to allow full access. This selection de-selects all countries shown.
   * *Click* **Restrict Access For All Countries** to restrict all countries. This selection is useful if only a few countries are to be allowed access; allowed countries can be *de-selected* to allow only certain countries.
   * *Click* **Restrict Access For All Countries Not Shipping To** to restrict access based on the countries selected in "Country Options" in the Magento store backend.
   * *Click* **UPDATE** to apply your selections

Any update to these restrictions may take up to 30 minutes to take effect since the updates are applied to the CloudFront Distribution configuration.
---
# Stratus Panel - Access > Block Bots
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/access-panel/block-bots/
Description: Extra "spiders" and indexing agent can increase site session traffic. Many are not useful and simply sap server resources. Webscale STRATUS gives you the ability to restrict bots by listing their User-Agent in this panel.


## Edit Bots List

> Remember, user-agents added to this list will be **blocked** from accessing the website.

 1. *Go to* **Access > Block Bots** in the Webscale STRATUS sidebar menu.
 * *Add* any user-agent you wish to the list. Each agent should be on a separate line. Each user-agent listed will block any user-agent that *contains* the name in the list.
 * *Click* **UPDATE** to save changes.

 > A user-agent value of "baidu" will block any user-agent containing "baidu" such as "baidu-agent," "baiduuserfromsomewhere," or "somebaiduagent."

 {{< figure src="/images/stratus/img/articles/botblock-1.png" alt="botblock-1-50" >}}
---
# Stratus Panel - Cron
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cron-panel/
Description: Info | Schedule

---
# Stratus Panel - Cron > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cron-panel/info/
Description: Webscale STRATUS makes it simple and easy to check the status of the Cron service that runs cron tasks according to a [schedule](/docs/reference/stratus/control-panels/cron-panel/schedule/).


## Checking Cron Status

To check the status of the Cron service *Go to* **Cron > Info** in the Webscale STRATUS sidebar menu. Webscale STRATUS will check the status of the Cron service.

The **Status** will show "Running" if the Cron service is active and show "Stopped" if it is not running.

 {{< figure src="/images/stratus/img/articles/cron-info-1.png" alt="Cron-Info-26" >}}

> Note that the Cron service does not run on [development environments](/docs/reference/stratus/about-webscale-stratus/environment-types/#development-environments/).

The Cron service may also be stopped by *clicking* **DISABLE**.

## Checking Crons via CLI

The status of Magento Crons can also be retrieved via Command-Line Interface (CLI) using a Terminal or Shell access app.

 1. *Connect* to the Webscale STRATUS environment using [SSH Access](/docs/reference/stratus/control-panels/ssh-panel/info/).
 * *Change directory* to the root directory of Magento.
 * *Run* `bash`.
 * *Run* `n98-magerun sys:cron:history` for **Magento 1.x** stores. *Run* `n98-magerun2 sys:cron:history` for **Magento 2.x** stores.
---
# Stratus Panel - Cron > Schedule
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cron-panel/schedule/
Description: The Webscale STRATUS control panel makes creating and managing Cron tasks quite simple.



> **WARNING:** do NOT add Cron tasks using the Crontab -e command via SSH. Your entries will be overwritten.

All Magento stores require a basic set of cron jobs to be set. Each cron job is a task executed according to a schedule. Additional cron tasks may be added as needed.

## Create a Cron Task

To create a new Cron task:

 1. *Go to* **Cron > Schedule** in the Webscale STRATUS sidebar menu.
 * *Click* **+ Add New Cron**.
   	* **Label** — *Enter* a name for the cron task for your use.
   	* **Enabled** — *Select* "Yes" to set the taks to active or "No" for inactive.
   	* **Command** — *Enter* the shell command to run at regular intervals. Be sure to use **full paths to binaries and other files**.
   > E.g., to run "mytask.php," the command might look like `/usr/bin/php /srv/mytask.php`.
   	* **Common Cron Settings** — *Select* one of the common interval settings or "Custom" to allow manual entry of interval values.
   > For help in creating manual interval settings, see [Crontab Guru](https://crontab.guru "Visit Crontab Guru").
 * *Click* **CREATE** to save the cron task.

 {{< figure src="/images/stratus/img/articles/cron-schedule-1.png" alt="Cron-38" >}}

## Edit a Cron Task

To **edit** an existing cron task, click on the name of the task in the left column. After updating the task information, *click* **UPDATE** to save changes.

## Delete a Cron Task

To **delete** an existing cron task, click on the name of the task in the left column. *Click* **DELETE** to remove the cron task.

> To keep the task, but stop it from activating, change **Enabled** to "No."
---
# Stratus Panel - Application
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/
Description: Stratus Template | Frontend URL | Multisite & Multistore | Maintenance Mode | Deployment Mode | Clear Cache | CLI Commands

---
# Stratus Panel - Application > Stratus Template
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/stratus-template/
Description: The Webscale STRATUS template updates theNginx configuration for the STRATUS environment.

Current options include:

  * Magento 2.2 (for Magento 2.2 and above)
  * Magento 2.1
  * Magento 2.0
  * Magento 1.X


## Change Template

 1. *Go to* **Application > Stratus Template** in the STRATUS sidebar menu.
 * *Select* the template most appropriate for the version of Magento installed.
 * *Click* **UPDATE** to save the change.

 > **NOTE:** Updating the template will relaunch STRATUS services, resulting in **1-2 minutes of downtime**.
---
# Stratus Panel - Application > Frontend URL
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/frontend-url/
Description: The Frontend URL is the secure base URL in Magento and also the URL that the main store will use when loading.


Frontend URLs must begin with `https://` or `http://` and end with a `/`.

> Example: `https://mysite.com/`

## Update Store Base URL

To **update** the Store Base URL:

  1. *Go to* **Application > Frontend URL** in the Webscale STRATUS sidebar menu.
  * *Enter* the desired store base URL.
  * *Click* **UPDATE** to save the changes.

{{< figure src="/images/stratus/img/articles/magento-frontend-url-1.png" alt="magento info-52" >}}

## Using HTTP only (no SSL)

Using non-secure, http only protocol is not possible on Stratus as it is a requirement by CloudFront.
---
# Stratus Panel - Application > Multisite and Multistore
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/multistore/
Description: One of Magento's unique strengths is its ability to create and manage multiple stores from a single Magento installation. If the Magento store installed is configured for multiple stores, this panel configures the Nginx web server to properly map domains to the appropriate website, store, or store view.




> Store domains can point to a Magento Website or Store scope depending on your needs.

Configuration of the Nginx server requires the following items:

  * Domain names used.
  * Website, Store, or Store View Codes for each domain, found in **Stores > Manage Stores** in the Magento Admin.

{{< figure src="/images/stratus/img/articles/magento-multistore-1.png" alt="multistore-45" >}}

With the gathered information, compose each directive by a combination of domain-code-scope, with each component separated by a space, comma, or semicolon.

For example, for the domain "clothes.com" assigned to a Store scope in Magento, the directive would be composed as `clothes.com clothing_website_store store`.

To configure Nginx,

  1. *Go to* **Application> Multisite & Multistore** in the STRATUS sidebar menu.
  * *Enter* each domain-code-scope combination on a separe line.
  * *Click* **UPDATE** to save the configuration.

After each update, Nginx will be configured with the proper store directives.

 {{< figure src="/images/stratus/img/articles/magento-multistore-2.png" alt="multistores-48" >}}

If you would like to use the same domain name, but use different stores per subfolder (such as /us, /ca, /fr, /en, etc.), you can use the [subfolder method](/docs/reference/stratus/guides/general/multistore-subfolders/ "Subfolder Multistore Configuration Method"/).
---
# Stratus Panel - Application > Maintenance Mode
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/maintenance-mode/
Description: Maintenance mode can be toggled on and off in Webscale STRATUS. Sites in maintenance mode present a 503 status page to site visitors.



> This function is the same as running `php bin/magento maintenance:enable`

## Enable Maintenance Mode

To **enable** Magento Maintenance Mode,

  1. *Go to* **Application > Maintenance Mode** in the Webscale STRATUS sidebar menu.
  * *Select* "Maintenance Mode Enabled"
  * *Click* **UPDATE** to save the change.

  {{< figure src="/images/stratus/img/articles/magento-maintenance-mode-2.png" alt="maintenance mode-87" >}}

## Disable Maintenance Mode

To **disable** Maintenance Mode,

  1. *Go to* **Application > Maintenance Mode** in the Webscale STRATUS sidebar menu.
  * *Deselect* "Maintenance Mode Enabled"
  * *Click* **Update** to save the change.

  {{< figure src="/images/stratus/img/articles/magento-maintenance-mode-1.png" alt="maintenance mode-87" >}}
---
# Stratus Panel - Application > Deployment Mode
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/deployment-mode/
Description: The store deployment mode refers to the [Magento 2 modes](/docs/reference/stratus/guides/magento-2/set-magento-2-modes/).



> Changing the mode here is equivalent to the `php bin/magento deploy:mode:set <mode>` command.

 {{< figure src="/images/stratus/img/articles/magento-deployment-mode-1.png" alt="Deployment Mode" >}}

To set the deployment mode for the Magento installation,

  1. *Go to* **Application > Deployment Mode** in the STRATUS sidebar menu.
  * *Select* the desired deployment mode.
  * *Click* **UPDATE** to save and inact the changes.

Depending on the chosen mode, changes may take some time to complete. *Production* mode will initiate a compilation and other processes that will set a Magento 2 store into *Maintenance* mode until completed.

&nbsp;
---
# Stratus Panel - Application > Clear Cache
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/clear-cache/
Description: In this panel, all Magento and Varnish caches can be cleaned.



> Equivalent to running `php bin/magento cache:clean`.

To clear the Magento and Varnish caches,

  1. *Go to* **Application > Clear Cache** in the STRATUS sidebar menu.
  * *Click* **CLEAR CACHE**

The results of the operation will be displayed in the **Result** field when completed.

{{< figure src="/images/stratus/img/articles/magento-clear-cache-1.png" alt="Clear Cache screen" >}}
---
# Stratus Panel - Application > CLI Commands
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/application-panel/cli-commands/
Description: As a shortcut to accessing Webscale STRATUS via SSH and manually running commands, the platform provides a long list of Magento-related commands.


> **NOTE**: Take caution when using these commands, as some may temporarily disable a Magento store or result in unfavorable results.

Some commands require arguments in order to properly work. For each selected command, *Help* about each command can be accessed for guidance on any required arguments.

To **run** any command,

  1. *Go to* **Application > CLI Commands** in the Webscale STRATUS sidebar menu.
    * **Step 1.** — *Select* the desired command.
	* **Step 2.** — *Enter* any command arguments if applicable for the chosen command.
  * *Click* **RUN COMMAND**.

 Results of the command will appear in the **Result** field.

> For help on any command, *select* the command under **Step 1** and *click* **Get Help About Command**.

## Example Command

As an example of using the CLI Commands panel, consider running the command to create an Admin user.

To understand the arguments needed,

  1. *Select* "admin:user:create - Creates an administrator" from **Step 1**.
  * *Click* **GET HELP ABOUT COMMAND**.

In the **Result** field, the usage and options for the select command are shown. From this panel, the following arguments are noted:

  * **--admin-user=ADMIN-USER** — (Required) Admin user
  * **--admin-password=ADMIN-PASSWORD** — (Required) Admin password
  * **--admin-email=ADMIN-EMAIL** — (Required) Admin email
  * **--admin-firstname=ADMIN-FIRSTNAME** — (Required) Admin first name
  * **--admin-lastname=ADMIN-LASTNAME** — (Required) Admin last name

To build the arguments needed for this example command, the following would be assembled and entered into **Step 2**:

	--admin-user testuser1 --admin-password ohyeah1234 --admin-email mytest@somestore.com --admin-firstname mage --admin-lastname wakka

After entering these arguments and clicking **RUN COMMAND**, STRATUS would send the command to the Magento store and an Admin user would be created.

  {{< figure src="/images/stratus/img/articles/cli_command_run.png" alt="cli_command_run-81" >}}
---
# Stratus Panel - CloudFront
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cloudfront-panel/
Description: Info | HTTP2 | SSL | Compression

---
# Stratus Panel - CloudFront > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cloudfront-panel/info/
Description: On Webscale STRATUS, all traffic is sent through the Amazon Cloudfront CDN. Assets are cached at edge nodes based on geographic location, resulting in faster page rendering.


> To fully understand how CloudFront operates within AWS, see the [AWS CloudFront documentation](https://docs.aws.amazon.com/cloudfront/index.html#lang/en_us).


{{< figure src="/images/stratus/img/articles/cloudfront-1.png" >}}

To view and manage CloudFront for an environment, *go to* **CloudFront > Info** in the Webscale STRATUS sidebar menu.

  * *Click* **ENABLE** to turn on CloudFront caching.
  * *Click* **DISABLE** to turn off CloudFront caching. No assets will be cached. Traffic to the server is still directed through the CloudFront WAF.
  * *Click* **FLUSH CACHE** to reset the cache by invalidating the current CDN cache. Subsequent requests will rebuild the CloudFront cache.
---
# Stratus Panel - CloudFront > HTTP2
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cloudfront-panel/http2/
Description: HTTP2 is recommended and is the default setting in Webscale STRATUS. In some rare cases, HTTP2 must be disabled for legency code.



{{< figure src="/images/stratus/img/articles/cloudfront-2.png" >}}

To change the HTTP2 setting, *go to* **CloudFront > HTTP2** in the STRATUS sidebar menu.

  * **CloudFront HTTP2** — *Select* to enable.
  * *Click* **UPDATE** to save changes.
---
# Stratus Panel - CloudFront > SSL
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cloudfront-panel/ssl/
Description: By default *Force SSL* is set to redirect all HTTP requests to HTTPS. This is the preferred setting.


By default *Force SSL* is set to redirect all HTTP requests to HTTPS. This is the preferred setting. Paths are preserved (e.g. http://store.com/about-us will be automatically redirected to https://store.com/about-us).

{{< figure src="/images/stratus/img/articles/cloudfront-3.png" >}}

To change the SSL setting, *go to* **CloudFront > SSL** in the STRATUS sidebar menu.

  * **CloudFront Force SSL** — *Select* to enable.
  * *Click* **UPDATE** to save changes.
---
# Stratus Panel - CloudFront > Compression
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/cloudfront-panel/compression/
Description: By default, stratus uses GZIP compression. In comparison, Gzip has 9 levels of compression, while Brotli has 11.


   If you would like to use Brotli instead, you may switch this under Cloudfront->Compression.

{{< figure src="/images/stratus/img/articles/cfc1.jpg" >}}

_Note: Changing the compression format from gzip to brotli for the first time will trigger the restart of nginx container._

{{< figure src="/images/stratus/img/articles/cfc2.jpg" >}}
---
# Stratus Panel - Nginx > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nginx-panel/info/
Description: Nginx configurations are managed by Webscale STRATUS and carefully configured to optimize the version of Application installed.


To view or reload the Nginx configuration, *go to* **Nginx > Info** in the Webscale STRATUS sidebar menu.

  * *Click* **RELOAD** to reload the Nginx configuration after any update and change has been made in its configuration.
  * *Copy* the Nginx configuration for review and use by *clicking* the **copy icon** in the *Nginx Configuration* field.

{{< figure src="/images/stratus/img/articles/nginx-1.png" >}}
---
# Stratus Panel - Nginx
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nginx-panel/
Description: Info | Document Root | Redirects | Includes

---
# Stratus Panel - Nginx > Document Root
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nginx-panel/document-root/
Description: The *document* or *web* root of your site is the top-level directory where your site files or application resides.


For both Magento 1 and 2, this is where the *index.php* file is located.

On a Magento 1 site, the following are common files found in the document root directory:

  * index.php
  * media
  * skin
  * js

For Magento 2, the following are found in the document root directory:

  * index.php
  * pub
  * generation (Magento 2.2)

> **NOTE:** changing the document root directory can have unexpected consequences to your environment. Changes to this setting should be carefully considered. Webscale STRATUS can only support one document root.

To change the document root for a Webscale STRATUS install,

  1. *Go to* **Nginx > Document Root** in the STRATUS sidebar menu.
  {{< figure src="/images/stratus/img/articles/nginx-2.png" >}}
  2. *Click* the **folder icon** to the right of the directory field to open a dialog for selecting or adding a new directory.
  3. *Select* a directory in the modal selector to select an existing directory.
    * *Click* on directory names to navigate to a nested directory.
	* *Click* on directories in the **Current Path** field to navigate to parent directories.
  4. To add a new directory, *navigate* to the desired parent directory.
    * *Enter* the name of the new directory in the bottom field.
	* *Click* **Add New Directory**.
  5. *Click* **SELECT** to save your choice.
  6. *Click* **UPDATE** to commit your change.

STRATUS will configure Nginx and attempt to load the web application in the selected directory.
---
# Stratus Panel - Nginx > Redirects
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nginx-panel/redirects/
Description: File path redirects to other URLs can be easily added to the Nginx configuration.

The formate of a redirect is `/From_Path=To_Path_URL`

{{< figure src="/images/stratus/img/articles/redirects.png" alt="STRATUS Redirects Panel" >}}

To configure redirects,

  1. *Go to* **Nginx > Redirects** in the STRATUS sidebar menu.
  2. *Enter* the desired redirects in the field. Put each redirect on a separate line.
  3. *Click* **UPDATE** to save changes.
---
# Stratus Panel - Nginx > Includes
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nginx-panel/includes/
Description: Custom Nginx directives can be powerful tools. Webscale STRATUS makes it easy to add includes.


> Nginx includes are easy to add in Webscale STRATUS, but can be difficult to master. Incorrectly coded includes can result in undesirable results and should never be added to a Production environment without fully testing on another environment.

The following are two examples provided by Stratus customers. ***Do not use these as-is on a Production environment and always test all includes on a non-Production environment before deploying.***

## WordPress

Add this to get WordPress working in a subdirectory of your web-root, substituting the *blog* path for the particular sub-directory.  

``` bash
location /blog/ {
index index.php index.html index.htm;
try_files $uri $uri/ /blog/index.php?$args ;
location ~* \.php$ { try_files /dummy @proxy; }
}

location /blog/wp-admin/ {
index index.php index.html index.htm;
try_files /blog/wp-admin/$uri /blog/wp-admin/$uri/ /blog/wp-admin/index.php?$args ;
location ~* \.php$ { try_files /dummy @proxy; }
}
```

## Custom PHP Scripts

The default Webscale STRATUS Nginx template does not allow PHP execution in directories not normally required by Applications. A special Nginx location is required if you have custom scripts or other PHP based code you need to run.

``` bash
location ~* my_custom_scripts/ {
try_files $uri $uri/ /index.php?$args;
location ~* \.php$ { try_files /dummy @proxy; }
}
```

Change **my\_custom\_scripts** in the example above to match your requirements.
---
# Stratus Panel - PHP > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/info/
Description: Webscale STRATUS provides visibility into the PHP configurations of an environment.


To view the PHP information, *go to* **PHP > Info** in the Webscale STRATUS sidebar menu.

{{< figure src="/images/stratus/img/articles/php-info-1.png" >}}

  * *Click* **RELOAD** to reload the PHP configuration. The **Status** value (Enabled/Disabled) refers to the PHP status service.
  * To copy any of the fields shown, *click* the **Copy Icon** in the upper-right of the field.

Webscale STRATUS provides additional tools related to managing PHP on a server:

  * **[Version](/docs/reference/stratus/control-panels/php-panel/version/)** allows the changing of the PHP version used.
  * **[Options](/docs/reference/stratus/control-panels/php-panel/options/)** provides for manually setting certain PHP parameters.
  * **[Blackfire](/docs/reference/stratus/control-panels/php-panel/blackfire/)** for enabling the Blackfire service.
  * **[Xdebug](/docs/reference/stratus/control-panels/php-panel/xdebug/)** for enabling Xdebug profiling.
---
# Stratus Panel - PHP
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/
Description: Info | Version | Options | Blackfire | Xdebug | Datadog | Tideways

---
# Stratus Panel - PHP > Version
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/version/
Description: Webscale STRATUS provides PHP 5.6 (EOL), 7.0 (EOL), 7.1 (EOL), 7.2, 7.3 and 7.4.


> Please note that PHP 5.6, 7.0, and 7.1 are [**End Of Life**](https://www.php.net/supported-versions.php)

## PHP Version
To change the version of PHP used:

  1. *Go to* **PHP > Version** in the Webscale STRATUS sidebar menu.
  2. *Select* the version of PHP desired.
  3. *Click* **UPDATE** to save changes.

  {{< figure src="/images/stratus/img/articles/phpcomposer.png" alt="php version-7" >}}

## Composer Version
To change the version of Composer used. (This option is only available for PHP 7.3+)

  1. *Go to* **PHP > Version** in the Webscale STRATUS sidebar menu.
  2. *Select* the version of Composer desired. _note: Composer 2 is required for Magento 2.4.3+ Release Date: April 27 2021_
  3. *Click* **UPDATE** to save changes.
---
# Stratus Panel - PHP > Options
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/options/
Description: PHP values can be set to override the defaults in Webscale STRATUS.


 {{< figure src="/images/stratus/img/articles/php-options-1.png" alt="options-96" >}}

To update PHP configuration values:

  1. *Go to* **PHP > Options** in the STRATUS sidebar menu.
  2. *Edit* the PHP values in the field.
  3. *Click* **UPDATE** to save changes.
---
# Stratus Panel - PHP > Blackfire
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/blackfire/
Description: Webscale STRATUS includes the ability to communicate with the Blackfire service for testing and improving PHP performance.


 {{< figure src="/images/stratus/img/articles/blackfire-1.png" alt="Blackfire panel" >}}

To enable Blackfire:

  1. *Go to* **PHP > Blackfire** in the Webscale STRATUS sidebar menu.
  	* **Blackfire Service** — *Click* **ENABLE**.
	* **Server ID** — *Enter* the Server ID value provided by Blackfire.
	* **Server Token** — *Enter* the Server token provided by Blackfire.
  2. *Click* **UPDATE** to save changes.
---
# Stratus Panel - PHP > Xdebug
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/xdebug/
Description: Webscale STRATUS support Xdebug.


 {{< figure src="/images/stratus/img/articles/xdebug-1.png" alt="Xdebug panel" >}}

To enable Xdebug:

  1. *Go to* **PHP > Xdebug** in the Webscale STRATUS sidebar menu.
  	* **Xdebug Service** — *Click* **ENABLE**.
	* **Trace File Output Format** — *Select* the format for the debugging output.
	* **Trace Enable Trigger Value** — Used for triggering the tracer using a browser plugin.
	* **Profiler Enable Trigger Value** — Used for enabling profiling with a browser plugin.
	* **IDE Key** — *Enter* a default *IDE Key* value, such as "xdebug.atom" for Atom IDE.
  2. *Click* **UPDATE** to save changes.
---
# Stratus Panel - PHP > Datadog
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/datadog/
Description: Webscale STRATUS support Datadog.



 {{< figure src="/images/stratus/img/articles/datadog.png" alt="Xdebug panel" >}}

To enable Datadog:

  1. *Go to* **PHP > Datadog** in the Webscale STRATUS sidebar menu
  2. **License Key** — *Enter* license key provided by Datadog
  3. *Click* **UPDATE** to save changes.
  3. Under **Service** — *Click* **ENABLE**.
---
# Stratus Panel - PHP > Tideways
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/php-panel/tideways/
Description: Webscale STRATUS supports Tideways.



To enable Tideways:

  1. *Go to* **PHP > Tideways** in the Webscale STRATUS sidebar menu.
  	* **Tideways** — *Click* **ENABLE**.
	* **API Key** — *Enter* a the *API Key* value given to you by Tideways.
  2. *Click* **UPDATE** to save changes.
---
# Stratus Panel — NodeJS > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nodejs-panel/info/
Description: Enable NodeJS for headless environments.


Webscale STRATUS includes the ability to enable NodeJS for [headless environments](/docs/reference/stratus/guides/optimizations/pwa-and-headless-commerce/) like [PWA Studio](https://devdocs.magento.com/guides/v2.4/pwa/) and [Vue Storefront](https://www.vuestorefront.io/).

{{< figure src="/images/stratus/img/articles/nodejs-1.jpg" >}}

> **NOTE:** before enabling the NodeJS container, complete the initial [configuration](/docs/reference/stratus/guides/pwa-configuration/).

To manage the NodeJS service, *go to* **NodeJS > Info** in the STRATUS sidebar menu.

  * To enable NodeJS, *click* **ENABLE**.
  * To disable NodeJS, *click* **DISABLE**.

> There may be 1-2 minutes of downtime why the Webscale STRATUS environment restarts.
---
# Stratus Panel - NodeJS
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nodejs-panel/
Description: Info | PWA

---
# Stratus Panel — NodeJS > PWA
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/nodejs-panel/pwa/
Description: Webscale STRATUS includes the ability to enable NodeJS for headless environments.


{{< figure src="/images/stratus/img/articles/nodejs-pwa.jpg" >}}

Here you will see all the domains applied to your headless environment.

You may choose to set them to PHP or NodeJS. Selecting either changes the fastcgi backend proxy in the Nginx configuration.
 If a domain is set to PHP, it will forward to PHP-FPM. (/srv/public_html/ or [custom docroot](/docs/reference/stratus/control-panels/nginx-panel/document-root/)/)
 If NodeJS is selected, the requests will be routed to NodeJS. (/srv/pwa/)

This way you can host normal Magento 2 or PHP views alongside separate PWA applications for your store. Select and configure each domain as needed for your application.
---
# Stratus Panel - MySQL > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/mysql-panel/info/
Description: Webscale STRATUS provides easy access to the MySQL configuration values and processes.


> There is currently no phpMyAdmin or other visual DB editor available on Webscale STRATUS. It is recommended to utilize mysql-cli, or remote MySQL connection

{{< figure src="/images/stratus/img/articles/mysql-info-1.png" >}}
{{< figure src="/images/stratus/img/articles/mysql-info-2.png" >}}

  * To restart the MySQL server instance, *click* **RESTART**.
  * To copy any field, *click* the **copy icon** in the upper-right of any field.

## Using MySQL Commands

The database on Webscale STRATUS can be accessed directly via the **mysql** command or the **n98-magerun** and **n98-magerun2** (Magento 2) tools can be used with credentials already set in _local.xml_ or _env.php_ of the Magento store.

### Connecting to the database

Use the value shown in the **Connection Details** field to access the database via Command Line Interface (CLI):

``` bash
mysql -h mysql -uUSERNAME -pPASSWORD DATABASENAME
```
To run the n98-magerun commands,  use the following CLI commands via SSH:

  * For Magento 1: `n98-magerun db:console`
  * For Magento 2: `n98-magerun2 db:console`

## Dropping and Recreating a Database

Using the database credentials, a MySQL database can be dropped and recreated:

``` bash
mysqladmin -h mysql -uUSERNAME -pPASSWORD drop DATABASENAME
mysqladmin -h mysql -uUSERNAME -pPASSWORD create DATABASENAME
```
---
# Stratus Panel - MySQL
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/mysql-panel/
Description: Info | Processlist | Users

---
# Stratus Panel - MySQL > Process List
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/mysql-panel/process-list/
Description: To help diagnose issues with MySQL, Webscale STRATUS provides a full listing of all processes for quick review.


{{< figure src="/images/stratus/img/articles/mysql-process-list-1.png" >}}

To view MySQL processes, *go to* **MySQL > Process List** in the Webscale STRATUS sidebar menu.

  * To copy the process list for use elsewhere, *click* the **copy icon** in the upper-right of the field.
  * To refresh the process list, *click* **<ins>Refresh</ins>** in the lower left corner.
---
# Stratus Panel - MySQL > Databases
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/mysql-panel/databases/
Description: Webscale STRATUS Database creation and deletion


**Adding a database**: To add a database, type the database name and click the + symbol.

**Removing a database**: To remove a database, click the trashcan symbol next to the database name.

{{< figure src="/images/stratus/img/articles/db.png" >}}

> **NOTE:** The main database and user that is provided to you for your environment will not be listed here. This section is dedicated only for additional databases. You may view the details for your main database under [Mysql -> Info](/docs/reference/stratus/control-panels/mysql-panel/info/)
---
# Stratus Panel - MySQL > Users
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/mysql-panel/users/
Description: Webscale STRATUS Database user creation and deletion


**Adding a user**: To add a database user, type the user name, hostname and password then click the CREATE button. *% (wildcard) may be used as a default for the hostname.*

**Removing a user**: To remove a database user, click the user in question then click the DELETE button.

{{< figure src="/images/stratus/img/articles/db2.png" >}}

Once a database user is created, you will find permission settings at the bottom of that user's screen per database.

{{< figure src="/images/stratus/img/articles/db3.png" >}}

> **NOTE:** The main user that is provided to you for your environment will not be listed here. This section is dedicated only for additional users. You may view the details for your main database and user under [Mysql -> Info](/docs/reference/stratus/control-panels/mysql-panel/info/)
---
# Stratus Panel - Memcache
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/info/
Description: All Magento stores on Webscale STRATUS are [required to use either [Redis or Memcache](/docs/reference/stratus/about-webscale-stratus/magento-requirements/).


If the environment is using Memcache, *go to* **Memcache > Info**.

{{< figure src="/images/stratus/img/articles/memcache-info-1.png" >}}

  * To flush the cache, *click* **FLUSH CACHE**.
  * To copy any field value for other use, *click* the **copy icon** in the upper-right of any field.
---
# Stratus Panel - Redis > Full Page Cache
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/redis-panel/full-page-cache/
Description: Webscale STRATUS enables Redis for Full Page Cache (FPC) by default.

{{< figure src="/images/stratus/img/articles/redis-fpc-1.png" >}}

To view and flush the Redis cache, *go to* **Redis > Redis Full Page Cache** in the Webscale STRATUS sidebar menu.

  * To flush the cache, *click* **FLUSH CACHE**.
  * *Choose* the version of Redis.
  * *Click* **UPDATE** to commit the version change.
  * To copy any field value, *click* the **copy icon** in the upper-right of any field.
---
# Stratus Panel - Redis
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/redis-panel/
Description: Redis Full Page Cache | Config Cache | Sessions

---
# Stratus Panel - Redis > Config Cache
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/redis-panel/config-cache/
Description: Webscale STRATUS allows you to enable Redis cache depending on your needs. For more on configuring Magento caches, see [**Configuring Caches**](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/)


{{< figure src="/images/stratus/img/articles/redis-config-cache-1.png" >}}

To enable Redis caches on STRATUS, *go to* **Redis > Config Cache** in the Webscale STRATUS sidebar menu.

  * To enable Redis cache, *click* **ENABLE**.
  * To disable Redis cache, *click* **DISABLE**
  * To flush the cache, *click* **FLUSH CACHE**

To set the version you wish to use, *choose* the version, then *click* **UPDATE**.
---
# Stratus Panel - Redis > Sessions
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/redis-panel/sessions/
Description: Webscale STRATUS allows you to enable Redis for storing sessions. For more on configuring Magento caches, see [**Configuring Session Cache**](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/)


{{< figure src="/images/stratus/img/articles/redis-sessions-1.png" >}}

To enable Redis sessions on STRATUS, *go to* **Redis > Sessions** in the Webscale STRATUS sidebar menu.

  * To enable Redis sessions, *click* **ENABLE**.
  * To disable Redis sessions, *click* **DISABLE**
  * To flush the cache, *click* **FLUSH CACHE**

To set the version you wish to use, *choose* the version, then *click* **UPDATE**.
---
# Stratus Panel - Varnish > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/varnish-panel/info/
Description: Webscale STRATUS allow you to manage and flush Varnish cache within the Control Panel.


> For more on configuration for Varnish, see **[Enabling Varnish on Stratus](/docs/reference/stratus/guides/webscale-stratus/enable-varnish-on-stratus/)**

![varnish](/images/stratus/img/articles/varnish-info-1.png)

 To access Varnish controls, *go to* **Varnish > Info** in the Webscale STRATUS sidebar menu.

   * To enable Varnish, *click* **ENABLE**.
   * To disable Varnish, *click* **DISABLE**
   * To flush the varnish cache, *click* **FLUSH CACHE**
   * To copy any field value for other use, *click* the **copy icon** in the upper-right of any field.
---
# Stratus Panel - Varnish
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/varnish-panel/
Description: Info | Version | VCL | URL cache

---
# Stratus Panel - Varnish > Version
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/varnish-panel/version/
Description: STRATUS allow you to select the version of Varnish you wish to employ on your installation.


> Magento 2.3.3+ supports Varnish version 6.

![varnish](/images/stratus/img/articles/varnish-version-1.png)

 To change your version,

   1. *Go to* **Varnish > Version** in the STRATUS sidebar menu.
   2. *Select* the version of Varnish you wish to run.
   3. *Click* **UPDATE** to save changes.

> **NOTE:** changing the version will cause a reboot of your installation.
---
# Stratus Panel - Varnish > VCL
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/varnish-panel/vcl/
Description: Webscale STRATUS allow you to configure a custom Varnish configuration for handling http traffic using Varnish Configuration Language (VCL).


![varnish](/images/stratus/img/articles/varnish-vcl-1.png)

 To add a custom VCL,

   1. *Go to* **Varnish > Info** in the Webscale STRATUS sidebar menu.
   2. *Select* **Custom VCL**.
   3. *Enter* the configuration in the **VCL** field.
   4. *Click* **UPDATE** to save changes.

> **NOTE:** there will be a short downtime as the system restarts with the new Varnish configuration.

> For more on configuration for Varnish, see **[Enabling Varnish on Stratus](/docs/reference/stratus/guides/webscale-stratus/enable-varnish-on-stratus/)**
---
# Stratus Panel - Varnish > URL Cache
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/varnish-panel/url-cache/
Description: Webscale STRATUS provides the ability to purge the Varnish cache of specific files and directories.


![varnish](/images/stratus/img/articles/varnish-url-cache-1.png)

 To purge specific items in the Varnish cache,

   1. *Go to* **Varnish > URL Cache** in the Webscale STRATUS sidebar menu.
   2. *Select* the **Base URL** for the items to be purged.
   3. *Enter* a directory or file path in **Subpath**. Directory paths will purge all items in the target directory including sub-directories.
   4. *Click* **CLEAR CACHE**.
---
# Stratus Panel - Elasticsearch
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/elasticsearch-panel/
Description: Info | Version | Configuration

---
# Stratus Panel - Elasticsearch > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/elasticsearch-panel/info/
Description: Elasticsearch is a powerful search tool to replace slower MySQL searches.


Elasticsearch indexes a Magento store and provides rapid search results for customers.

With Magento 2.3+, Elasticsearch is available to Magento Community stores. Magento 1.x stores can use Elasticsearch through third-party extensions.

You can change the version of Elasticsearch under <a href="/reference/stratus/control-panels/elasticsearch-panel/version/">Elasticsearch -> Version</a>.

You must also <a href="/reference/stratus/guides/magento-2/elasticsearch-and-elasticsuite/">configure Magento to use Elasticsearch</a>.

{{< figure src="/images/stratus/img/articles/elasticsearch-1.png" >}}

To view the status of Elasticsearch in Webscale STRATUS, *go to* **Elasticsearch > Info** in the STRATUS sidebar menu.

  * To enable Elasticsearch, *click* **ENABLE**.
  * To disable Elasticsearch, *click* **DISABLE**
  * To copy any field value for other use, *click* the **copy icon** in the upper-right of the field.

> Enabling or disabling Elasticsearch will restart the Webscale STRATUS environment and will result in 1-2 minutes of downtime.
---
# Stratus Panel - Elasticsearch > Version
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/elasticsearch-panel/version/
Description: Webscale STRATUS allows for the choice of different versions of <a href="/reference/stratus/control-panels/elasticsearch-panel/info/">Elasticsearch</a>.


  * Older extensions for Magento 1 will require version 2.x (e.g. version 2.3, version 2.4) depending on the requirements of the extension.
  * For Magento Community 2.3+, please check the supported version here: [System Requirements](https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html)

{{< figure src="/images/stratus/img/articles/elasticsearch-2.png" >}}

To change the Elasticsearch version,

  1. *Go to* **Elasticsearch > Version** in the Webscale STRATUS sidebar menu.
  2. *Select* the desired Elasticsearch version from the dropdown.
  3. *Click* **UPDATE** to save the changes.


You must also <a href="/reference/stratus/guides/magento-2/elasticsearch-and-elasticsuite/">configure Magento to use Elasticsearch</a>.
---
# Stratus Panel - Elasticsearch > Configuration
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/elasticsearch-panel/configuration/
Description: For advanced users, Webscale  STRATUS provides an interface to allow setting Elasticsearch parameters in the elasticsearch.yml file.


To access the Elastricsearch configuration panel, *go to* **Elasticsearch > Configuration** in the Webscale STRATUS sidebar menu.

After entering configurations, *click* **UPDATE**.
---
# Stratus Panel - Sphinx > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/sphinx-panel/info/
Description: Webscale STRATUS includes the ability to enable a Sphinx search service.



{{< figure src="/images/stratus/img/articles/sphinx-1.png" >}}

> **NOTE:** before enabling Sphinx, complete the initial [Sphinx configuration](/docs/reference/stratus/control-panels/sphinx-panel/configuration/).

To manage the Sphinx service, *go to* **Sphinx > Info** in the Webscale STRATUS sidebar menu.

  * To enable Sphinx, *click* **ENABLE**.
  * To disable Sphinx, *click* **DISABLE**.

> There may be 1-2 minutes of downtime why the Webscale STRATUS environment restarts.
---
# Stratus Panel - Sphinx
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/sphinx-panel/
Description: Info | Configuration

---
# Stratus Panel - Sphinx > Configuration
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/sphinx-panel/configuration/
Description: The Webscale STRATUS Sphinx service is designed for the Mirasvit Magento 2 search extension but may work for other modules.


Configure the Mirasvit extension with the following settings:

  * *Set* the **Engine** to "External Engine"
  * *Set* the **path** to "/usr/bin/searchd" on port 9312
  * *Set* the **host/ip** to "sphinx"
  * Under **Additional Configuration > Custom Base Path**, *add* "/srv/public_html/var/sphinx"
  * *Save* the configuration

This will generate a *sphinx.conf* in `var/sphinx` in the Magento document root. This file must be generated before enabling Sphinx in the [Sphinx Info panel](/docs/reference/stratus/control-panels/sphinx-panel/info/).

The location of the configuration file should be set in the Sphinx Configuration panel.

{{< figure src="/images/stratus/img/articles/sphinx-2.png" >}}

  1. *Go to* **Sphinx > Configuration** in the Webscale STRATUS sidebar menu.
    * **Configuration** —*Enter* any configuration customizations.
	* **Path to Config File** — *Edit* the file path to the Sphinx configuration file.
  2. *Click* **UPDATE**.
  3. *Click* **REINDEX** to force a re-index of the Sphinx service.

> Re-indexing should be completed after any configuration update.
---
# Stratus Panel - RabbitMQ > Info
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/rabbitmq-panel/info/
Description: Webscale STRATUS provides tools for enabling and [configuring the RabbitMQ messaging service](/docs/reference/stratus/control-panels/rabbitmq-panel/configuration/)..


{{< figure src="/images/stratus/img/articles/rabbitmq-1.png" >}}

To manage the RabbitMQ service, *go to* **RabbitMQ > Info** in the Webscale STRATUS sidebar menu.

  * To enable RabbitMQ, *click* **ENABLE**.
  * To disable RabbitMQ, *click* **DISABLE**.
  * To reset all RabbitMQ data, *click* **RESET DATA**.
  * To copy the report information, *click* the **copy icon** in the upper-right of the **Report** field.

> **NOTE:** changing the service status will reploy all Webscale STRATUS services, resulting in a momentary downtime.
---
# Stratus Panel - RabbitMQ
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/rabbitmq-panel/
Description: Info | Version | Configuration

---
# Stratus Panel - RabbitMQ > Version
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/rabbitmq-panel/version/
Description: Webscale STRATUS provides different versions of RabbitMQ


To change the RabbitMQ version, *go to* **RabbitMQ > Version** in the Webscale STRATUS sidebar menu.

  * Select the correct version of RabbitMQ according to the [Magento System Requirements](https://devdocs.magento.com/guides/v2.4/install-gde/system-requirements.html).
  * *Click* **UPDATE**.

> **NOTE:** changing the service status will redeploy all Webscale STRATUS services, resulting in a momentary downtime.
---
# Stratus Panel - RabbitMQ > Configuration
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/rabbitmq-panel/configuration/
Description: In Webscale STRATUS, the default credentials can be configured. The credentials entered in STRATUS *must* match the credentials in the *env.php* file.


> These credentials are only used during the initial deployment of RabbitMQ. If these credentials are changed after starting RabbitMQ, the change will not affect an existing user. See [Configuring RabbitMQ](/docs/reference/stratus/guides/general/configuring-rabbitmq/) for more information.

{{< figure src="/images/stratus/img/articles/rabbitmq-2.png" >}}

To update the RabbitMQ credentials,

  1. *Go to* **RabbitMQ > Configuration** in the Webscale STRATUS sidebar menu.
  2. *Enter* the RabbitMQ credentials.
  3. *Click* **UPDATE** to save changes.
---
# Stratus Panel - Vitals
URL: https://docs.webscale.com/docs/reference/stratus/control-panels/general-panel/stratusvitals/
Description: Webscale STRATUS Vitals is an application performance monitoring toolset to give you deep insight and clear visibility into how your environment is performing.




## Alerts

{{< figure src="/images/stratus/img/articles/vitals-alerts.png" alt="http graphs" >}}

* **Uptime**: Uptime based as probe success within the chosen time frame. Only monitored if your environment is considered live.
* **Autoscaling Status**: This reports if [Autoscaling](/docs/reference/stratus/control-panels/autoscaling/#how-does-autoscaling-work/) is ON or OFF. If you are on a legacy Resource Based Plan (RBP), this will be N/A.
* **Status Codes**: HTTP Status Codes per domain within the chosen time frame. Only monitored if your environment is considered live.
* **Response Time**: Response time in seconds within the chosen time frame. Only monitored if your environment is considered live.
* **Limit Hits**: This shows any service [limits](/docs/reference/stratus/about-webscale-stratus/limits/) you have hit within the chosen time frame. If you find your [production](/docs/reference/stratus/about-webscale-stratus/environment-types/) store routinely hitting [limits](/docs/reference/stratus/about-webscale-stratus/limits/), especially MySQL, the environment may need an upgrade.
* **All Errors**: Total errors the site has received within the chosen time frame.
* **Total Requests**: Total requests per second.
* **Checkout Errors**: Errors the site has received related to checkout within the chosen time frame.
* **API Errors**: Errors the site has received related to API within the chosen time frame.
* **Suspicious Traffic**: Malicious Traffic hits within the chosen time frame.

  > NOTE: Your environment is counted as live when it uses a domain other than its Webscale provided temporary domain name. [Development](/docs/reference/stratus/about-webscale-stratus/environment-types/#development-environment/) instances will not show this information.

## Overview

{{< figure src="/images/stratus/img/articles/vitals-over.png" alt="overview graphs" >}}

* **MySQL Total connections**: The total amount of MYSQL connections within the chosen time frame.
* **MySQL Query Runtime**: The average query Runtime for queries running in your environment.
* **MySQL Deadlocks**: MySQL locks that have occured in this environment within the chosen time frame.
* **Running Cron Processes**: The amount of running cron processes within the chosen time frame.
* **IO Read**: Input/Output reads to the file system and database for the environment within the chosen time frame.
* **IO Write**: Input/Output writes to the file system and database for the environment within the chosen time frame.
* **Pods not running**: The amount of pods not in the running state within the specified time frame. This can be due to a redeploy.
* **PHP-FPM Pod Count**: Count of PHP-FPM Pods. If [Autoscaling](/docs/reference/stratus/control-panels/autoscaling/#how-does-autoscaling-work/) is enabled, this graph will display the rise and fall of PHP-FPM pods which depends on the amount of traffic your environment is receiving. You will also see this change during [zero downtime deployments](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/) after a new set of pods is launched during a deploy & before a switch takes place.
* **Supervisor Alert Events**: A graphical representation of Supervisor events that have occured within the chosen time frame.
* **Supervisor Alert List**: This is a list of Alerts related to Health checks in your environment such as [Runaway MySQL processes](/docs/reference/stratus/health-checks/alerts-mysql/), [Runaway Crons](/docs/reference/stratus/health-checks/alerts-cron/), or High [IO](/docs/reference/stratus/health-checks/alerts-io/), [CPU](/docs/reference/stratus/health-checks/alert-cpu/), [Swap Memory](/docs/reference/stratus/health-checks/alerts-mem/) or [Load Average](/docs/reference/stratus/health-checks/alerts-load/).


## Service Detail

Webscale STRATUS Vitals provides CPU & Memory information for the services in your environment.

### MySQL

* **CPU % of Limit**: MySQL CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: MySQL Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by MySQL.
* **MEM Total**: The total amount of Memory used by MySQL. If this is high, it can signify that you need to upgrade your plan.

{{< figure src="/images/stratus/img/articles/vitals-mysql.png" alt="mysql graphs" >}}

### PHP-FPM

* **CPU % of Limit**: PHP-FPM CPU usage as a percentage of the limit.
* **MEM % of Limit**: PHP-FPM Memory usage as a percentage of the limit.
* **CPU Total**: The total amount of CPU cores used by PHP-FPM pods.
* **MEM Total**: The total amount of Memory used by PHP-FPM pods.

{{< figure src="/images/stratus/img/articles/vitals-php.png" alt="php graphs" >}}

### Cron

* **CPU % of Limit**: Cron CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: Cron Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by Cron.
* **MEM Total**: The total amount of Memory used by Cron.

{{< figure src="/images/stratus/img/articles/vitals-cron.png" alt="cron graphs" >}}

### Redis

* **CPU % of Limit**: Redis, Redis Config Cache & Redis Session CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: Redis, Redis Config Cache & Redis Session Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by Redis, Redis Config Cache & Redis Sessions.
* **MEM Total**: The total amount of Memory used by Redis, Redis Config Cache & Redis Sessions.

{{< figure src="/images/stratus/img/articles/vitals-redis.png" alt="redis graphs" >}}

### Varnish

* **CPU % of Limit**: Varnish CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: Varnish Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by Varnish.
* **MEM Total**: The total amount of Memory used by Varnish.

{{< figure src="/images/stratus/img/articles/vitals-varnish.png" alt="varnish graphs" >}}

### SSH

* **CPU % of Limit**: SSH usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: SSH Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by the SSH container.
* **MEM Total**: The total amount of Memory used by the SSH container.

{{< figure src="/images/stratus/img/articles/vitals-ssh.png" alt="ssh graphs" >}}

### Elasticsearch

* **CPU % of Limit**: Elasticsearch CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: Elasticsearch Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by Elasticsearch.
* **MEM Total**: The total amount of Memory used by Elasticsearch.

{{< figure src="/images/stratus/img/articles/vitals-es.png" alt="es graphs" >}}

### RabbitMQ

* **CPU % of Limit**: RabbitMQ CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: RabbitMQ Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by RabbitMQ.
* **MEM Total**: The total amount of Memory used by RabbitMQ.

{{< figure src="/images/stratus/img/articles/vitals-rabbit.png" alt="rabbit graphs" >}}

### NodeJS

* **CPU % of Limit**: NodeJS CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: NodeJS Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by NodeJS.
* **MEM Total**: The total amount of Memory used by NodeJS.

{{< figure src="/images/stratus/img/articles/vitals-node.png" alt="node graphs" >}}

### Sphinx

* **CPU % of Limit**: Sphinx CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: Sphinx Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by Sphinx.
* **MEM Total**: The total amount of Memory used by Sphinx.

{{< figure src="/images/stratus/img/articles/vitals-sphinx.png" alt="sphinx graphs" >}}

### Memcache

* **CPU % of Limit**: Memcache CPU usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **MEM % of Limit**: Memcache Memory usage as a percentage of the limit provided by your [plan](/docs/reference/stratus/about-webscale-stratus/limits/).
* **CPU Total**: The total amount of CPU cores used by Memcache.
* **MEM Total**: The total amount of Memory used by Memcache.

{{< figure src="/images/stratus/img/articles/vitals-memcache.png" alt="memcache graphs" >}}
---
# Stratus Guides - Deploying
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/deploy-to-stratus/
Description: Webscale STRATUS simplifies code deployments like never before.


Despite the incredible sophistication of the Webscale STRATUS cloud platform, Webscale STRATUS deployments are fairly straightforward and familiar.

## Pre-checks:

  * Make sure that all symlinks are using absolute paths.
  * Note that CloudFront may take up to 15 minutes to clear.

## Deployment Examples

To deploy code to Webscale STRATUS, [use SSH](/docs/reference/stratus/control-panels/ssh-panel/info/) and push the code, move symlinks, and flush caches. The built-in [CLI commands](/docs/reference/stratus/control-panels/application-panel/cli-commands/) provided in the Webscale STRATUS Control panel can also be used to assist.

See the following deployment examples:

  * [Standard Zero Downtime Deployment Example](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/)
  * [Detailed Zero Downtime Deployment Example](https://github.com/magemojo/mojo_stratus_deploy_example)
  * [Deployer.org Example](https://github.com/magemojo/deployer-example)

## Troubleshooting
You can see pod status change during deployment under the [General-> Pods](/docs/reference/stratus/control-panels/general-panel/pods/) section.

When using a deployment tool such as Jenkins, Capistrano, Deployer or similar where deployment changes/recreates a new symlink, please note that you should [clear the var/cron directory afterward and empty the cron_schedule table in the database](/docs/reference/stratus/guides/general/debugging-cron-tasks/#restarting-stopped-crons/).

See also:

  * <a href="/reference/stratus/guides/webscale-stratus/stratus-cli/">STRATUS Cli</a>
  * <a href="/reference/stratus/guides/general/using-symlinks/">Using Symlinks</a>
---
# Stratus - Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/
Description: Stratus Specific | General | Optimization | SSH and SFTP | DNS and SSL | Database | Cache and Sessions | Security | Magento 1 | Magento 2 | PWA

---
# Stratus Specific Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/
Description: <a href="/reference/stratus/guides/webscale-stratus/deploy-to-stratus/">Deploying</a> | <a href="/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/">Zero Downtime Deployment</a> | <a href="/reference/stratus/guides/webscale-stratus/go-live-on-stratus/">Going Live</a> | <a href="/reference/stratus/guides/webscale-stratus/stratus-cli/">Stratus CLI</a> | <a href="/reference/stratus/guides/webscale-stratus/default-crons/">Cron Configurations</a> | <a href="/reference/stratus/guides/webscale-stratus/newrelic-on-stratus/">New Relic</a> | <a href="/reference/stratus/guides/webscale-stratus/cloudflare-and-stratus/">Cloudflare Setup</a> |  <a href="/reference/stratus/guides/webscale-stratus/angularjs-on-stratus/">AngularJS</a> | <a href="/reference/stratus/guides/webscale-stratus/install-ioncube-loader-on-stratus/">IonCube Loader</a> | <a href="/reference/stratus/guides/webscale-stratus/install-sourceguardian-on-stratus/">Sourceguardian</a> | <a href="/reference/stratus/guides/webscale-stratus/enable-varnish-on-stratus/">Using Varnish</a> | <a href="/reference/stratus/guides/webscale-stratus/using-supervisord/">Using SupervisorD</a> | <a href="/reference/stratus/guides/webscale-stratus/using-mailhog/">Using MailHog</a>

---
# Stratus Guides - Zero Downtime Deployment
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/
Description: Webscale STRATUS allows you to perform zero downtime Magento 2 deployments. For simple updates such as themes or adding minor code changes, this method will keep your site running while you update. If you are performing a larger upgrade, such as a full Magento version upgrade, please plan on downtime for your store and utilize maintenance mode.


**Autoscaling** must be enabled to use Zero Downtime Deployment (ZDD).  [Learn more about Autoscaling](/docs/reference/stratus/control-panels/autoscaling/).

## How it works

ZDD consists of two Webscale STRATUS CLI commands, the *zerodowntime.init* command followed by the *zerodowntime.switch* command.

Prior to running any of the commands, you should enable Autoscaling and the **Zero Downtime Deploy** option on the Autoscaling page in the Webscale STRATUS panel. Enabling ZDD may take up to a minute of downtime.

With autoscaling enabled, you can now perform zero downtime deploys.  An example flow:

* Deploy your updated code to your STRATUS environment.
* Run any needed M2 commands
* Run the init CLI command *stratus zerodowntime.init*
* Wait for the init to complete
* Run the switch command to switch over to the new code base *stratus zerodowntime.switch*

The init command creates additional PHP-FPM containers with your current code base.  When you call the switch command, Nginx is updated to point to the new containers, and the old containers are gracefully terminated.  Any remaining connections are allowed to complete on the older codebase.  During the init stage, the code you see within the SSH shell or over SFTP is not live, other than files in directories marked as *Shared* in the autoscaling configuration.  Autoscaling and the init phase copy your code to the PHP-FPM containers directly separate from what you see via SSH.  Even after the switch, changing code via SSH will not be reflected live without redeploying via ZDD or the *stratus autoscaling.reinit* command to copy the code back out to the PHP-FPM containers

## Detailed Example deployment

A detailed example of a deployment example is located in our <a href="https://github.com/magemojo/mojo_stratus_deploy_example">Gitub</a>

## Short Example deployment

Below is a short & simple example of a deployment script. At the beginning, all commands that edit or update the file system (the code base) like deploying static content etc should run.  After that, the init command deploys the code to new PHP-FPM containers. Once the initialization is complete, then you can switch over to the new code base (zerodowntime.switch).  Then all the caches are cleared. Clearing the PHP Opcache is not necessary since new PHP-FPM containers are created.


```

/usr/share/stratus/cli crons.stop
### PUSH NEW CODE/UPDATES HERE
### git pull etc
/usr/local/bin/php -dmemory_limit=8000M bin/magento setup:upgrade;
/usr/local/bin/php -dmemory_limit=8000M bin/magento setup:di:compile;
/usr/local/bin/php -dmemory_limit=8000M /usr/local/bin/composer dump-autoload --no-dev --optimize --apcu;
/usr/local/bin/php -dmemory_limit=8000M bin/magento setup:static-content:deploy --jobs=$(nproc);
/usr/share/stratus/cli zerodowntime.init;
/usr/share/stratus/cli zerodowntime.switch
echo "\e[41m****Flushing Magento, Varnish, Redis and CloudFront CDN cache at this stage****";
/usr/local/bin/php -dmemory_limit=8000M bin/magento cache:flush;
/usr/share/stratus/cli cache.cloudfront.invalidate
/usr/share/stratus/cli cache.varnish.clear;
redis-cli -h redis flushall && redis-cli -h redis-config-cache -p 6381 flushall;
echo "\e[41m****Deployment Finished Site Enabled and tested****";
status_code=$(curl -kI --header 'Host: {yourhost}.com' --write-out %{http_code} --silent --output /dev/null 'https://nginx/')
if [[ "$status_code" -ne 200 ]] ; then
  echo "Site not active $status_code please push script again"
else
  echo "\e[41m****Beginning Indexing****";
n98-magerun2 sys:cron:run indexer_reindex_all_invalid;
n98-magerun2 sys:cron:run indexer_update_all_views;
/usr/share/stratus/cli crons.start

```

## Note on symlinks

When using a deployment tool such as Jenkins, Capistrano, Deployer or similar where deployment changes/recreates a new symlink, please note that you should [clear the var/cron directory afterward and empty the cron_schedule table in the database](/docs/reference/stratus/guides/general/debugging-cron-tasks/#restarting-stopped-crons/).

## Note on split crons
Your cron pod will restart automatically with ZDD commands.
---
# Stratus Guides - Going Live
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/go-live-on-stratus/
Description: Webscale provides free migration to a new Webscale STRATUS environment. Consult our existing migration policy and how migrations work.


> Each store is unique and may require slight variations from the sequence shown. Developers may contact Stratus support for assistance. Webscale Stratus provides free migration to a new STRATUS environment. Please consult [how migrations work](/docs/reference/how-migrations-work/).

The following is a typical, example launch sequence on a Webscale STRATUS environment based on a an existing application that is migrated to STRATUS.

## Prepare the Webscale STRATUS Environment

Before any go-live, test a copy of the store for all functionality.

1. *Gather* the following information:

  * Application and version installed
  * PHP version at the current host
  * MySQL version at the current host

2. *Set* the [STRATUS PHP Version](/docs/reference/stratus/control-panels/php-panel/version/ "PHP Version Control Panel"/) and [STRATUS Template](/docs/reference/stratus/control-panels/application-panel/stratus-template/ "STRATUS Template Control Panel"/) for the intended installation.
3. The Stratus Migration team will upgrade MySQL to the appropriate version. If you are performing the migration yourself, you may [place a ticket with support](/docs/getting-started/support/) to complete this.

## Clear the Existing Install

Depending on options during purchase, a new Webscale STRATUS environment may have Magento 2 pre-installed with the document root at /srv/public_html/. Before copying a site, clear this data.

1. *Delete* everything in `public_html/`: *run* `rm -rf /srv/public_html/`.
2. Using the [database credentials](/docs/reference/stratus/control-panels/mysql-panel/info/ "STRATUS Database Management"/), drop and recreate the existing STRATUS database [via SSH](/docs/reference/stratus/control-panels/ssh-panel/info/ "SSH Information Control Panel"/).

		mysqladmin -h mysql -u USERNAME -pPASSWORD drop db_
		mysqladmin -h mysql -u USERNAME -pPASSWORD create db_

## Copy the Site

> Copying a site requires SSH access to the current host.

1. *Connect* to the STRATUS environment via SSH.
2. Once connected, *log into* the existing Magento server:

		ssh myuser@mycurrenthost.com

	> Some SSH logins may require slightly different SSH commands:

		#with key
		ssh -i /path/to/keyfile myuser@mycurrenthost.com
		#with custom port
		ssh -p 1234 myuser@mycurrenthost.com

3. *Create* a backup of the current database.

		#example database dump commands
		mysqldump -uUSERNAME -pPASSWORD DATABASENAME > migrate.sql
		#with n98
		n98-magerun2 db:dump

4. *Copy* the files and database dump to Webscale STRATUS.

5. From SSH in your STRATUS environment, *go to* the document root (e.g. `public_html/`).

6. *Run* `rsync -avz -e ssh myuser@mycurrenthost:/path/to/webroot/ .`

	> If there is a custom port or ssh key, additional quotes around the SSH command are needed: `rsync -avz -e "ssh -p 1234" myuser@mycurrenthost.com:/path/to/webroot/ .`

The copy will begin. A lot of media and/or a large database will take a more time. Output will stream onto the terminal screen.

## Initial Magento Configuration

Once the files and database dump transfer are complete, configure Magento within the Webscale STRATUS environment.

1. *Update* `local.xml` (Magento 1) or `env.php` (Magento 2) in `app/etc` with the proper database credentials from the **MySQL -> Info** panel of the Webscale STRATUS Management Control. *Set* the hostname to "mysql" (in contrast, many other systems have the hostname set as "localhost").

	* **Magento 1** example `local.xml` file:

			<resources>
			           <db>
			               <table_prefix><![CDATA[]]></table_prefix>
			           </db>
			           <default_setup>
			               <connection>
			                   <host><![CDATA[mysql]]></host>
			                   <username><![CDATA[USERNAME]]></username>
			                   <password><![CDATA[PASSWORD]]></password>
			                   <dbname><![CDATA[DATABASENAME]]></dbname>
			                   <initStatements><![CDATA[SET NAMES utf8]]></initStatements>
			                   <model><![CDATA[mysql4]]></model>
			                   <type><![CDATA[pdo_mysql]]></type>
			                   <pdoType><![CDATA[]]></pdoType>
			                   <active>1</active>
			               </connection>
			           </default_setup>
			       </resources>

	* **Magento 2** example `env.php` file:

			<? php
			'db' => [
			    'table_prefix' => '',
			    'connection' => [
			        'default' => [
			            'host' => 'mysql',
			            'dbname' => 'DATABASENAME',
			            'username' => 'USERNAME',
			            'password' => 'PASSWORD',
			            'model' => 'mysql4',
			            'engine' => 'innodb',
			            'initStatements' => 'SET NAMES utf8;',
			            'active' => '1'
			        ]
			    ]
			],
			?>

2. *Import* the database using `n98-magerun[2]`

		bash
		#from your Magento document or web root
		#magento 1
		n98-magerun db:import app/etc/mydump.sql
		#magento 2
		n98-magerun2 db:import app/etc/mydump.sql

	> The **pv** utility shows the progress while the import completes.

### Cache and Sessions Configuration

Next enable [Redis cache](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/ "Redis Cache Configuration"/). The [Redis > Full Page Cache](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/ "Redis Cache Configuration"/) panel will indicate the status of the Redis cache. Redis can also be used for [sessions cache](/docs/reference/stratus/guides/caches-and-sessions/stratus-sessions-for-magento-1-and-2/).

### Update Base URLs

For testing prior to launch, set the **[Base URL](/docs/reference/stratus/control-panels/domains/urls/)** of the new Magento store to the pre-configured and included *mojostratus.io* domain found in the **Urls** Admin panel.

At launch, this Base URL will be replaced with the domain(s) of the Magento store(s) to be served.

## Test the New Install

Before taking a new install "live," all functions, pages, and administrative tasks should be thoroughly checked. Add-ons and customizations should particularly be reviewed and tested.

Testing should include:

* Homepage
* Product pages
* Category pages
* Add to cart functionality
* Logging into the backend
* Any special modules you use
* Imports and exports
* [Cron configuration](/docs/reference/stratus/control-panels/cron-panel/schedule/ "Cron Scheduling"/)

If testing reveals errors, check:

* Chrome Web Inspector Console for errors and descriptions
* Magento logs
* Error logs for Nginx in `/log/error.log`
* PHP error logs in `/log/php-fpm/`

Check with MageMojo Support if needed for further assistance.

## Pre-Launch Preparations

### Switch Nameservers

Since Domain Name Server (DNS) propagation can take up to 24 hours, it can be prudent to set any relevant DNS records to a very short Time-to-Live (TTL), if allowed by the DNS server host.

For complete instructions on DNS settings, see our [DNS guide](/docs/reference/stratus/guides/dns-and-ssl/stratus-nameservers-and-dns/ "DNS Best Practices"/).

When switching to Route 53, it is recommended that the **nameserver** switch be made well ahead of time, as the nameserver propagation takes the longest to complete.

1. *Get* the current IP or IPs for each domain at your current DNS host.
2. *Go to* **DNS** in the Webscale STRATUS sidebar menu.

	{{< figure src="/images/stratus/img/articles/point_ahead.png" alt="point ahead-56" >}}

3. *Select* the appropriate DNS zone in the list shown. If none is showing, [*create* a new zone](/docs/reference/stratus/control-panels/domains/dns/#creating-a-new-zone/).
	* *Select* **Custom IP** in the **IP** section.
	* *Enter* the current IP for the domain as it is currently hosted.
4. *Add* any additional DNS records, such as *www* or mailserver domains.
4. *Click* **Update** to save the changes.

The step changes the nameservers at the domain registrar. The domain registrar is where the domain is registered, such as *GoDaddy* or *Google Domains*. It may not be the same provider as the DNS host.

*Update* the nameservers at the domain registrar. Use all four nameserver values shown at the top of the **DNS** Admin panel (in green).

*Repeat* this process for any other domains which will be used with the new store.

> DNS management can be complicated. If you are unfamiliar with domain name management or have any questions, please contact MageMojo Support.

### Other Preparations

A store may have a extra integrations, frameworks, and custom code to account for outside the scope of this guide. Use the following list as an initial guide for reviewing your environment configuration.

* Check all DNS zones for any custom records that link to websites maintained at other hosts (subdomains etc) or custom TXT/SRV records for validation. These DNS records will need to be copied to the Webscale STRATUS DNS when using the STRATUS Route 53 DNS system.
* Check all cron jobs are configured under the [Cron Management area](/docs/reference/stratus/control-panels/cron-panel/schedule/ "Cron Scheduling"/) needed for the store, including any custom cron jobs on the current host.
* Verify any non-Magento code/frameworks are working as expected (e.g. WordPress).

## Going Live

Follow these steps to complete your transfer to Webscale STRATUS.

1. *Place* the Magento store at the current host into maintenance mode to prevent additional orders. Failure to do so can cause a split DB situation where the same order numbers exist in two different databases for different orders. Put the new store into [maintenance mode](/docs/reference/stratus/control-panels/application-panel/maintenance-mode/ "Maintenance Control Panel"/).
2. In the DNS zones listed in the **DNS** Admin panel, *adjust* all the zones to point to the **CloudFront** endpoint instead of the current host (if the nameservers were set in advance as described above). Otherwise, switch the nameservers now.
3. As described in **Copy the Site** above, *re-copy* the store database over to Webscale STRATUS and any updated files. Make sure to drop the existing database first, then re-import it. **Don't overwrite the updated configuration files.**

		mysqladmin -h mysql -u user_ -pPASSWORD drop db_
		mysqladmin -h mysql -u user_ -pASSWORD create db_

4. *Go to* the **URLs** Admin panel in the Webscale STRATUS management panel. Make sure all the domains listed match the domains that are moving, including their www. form (i.e. _mysite.com and www.mysite.com_). See [STRATUS URLs List and Domains](/docs/reference/stratus/control-panels/domains/urls/ "Urls Control Panel"/) for more information.
5. *Wait* to allow the domains and cloudfront configuration to update. This may take as long as 15 minutes to complete.
6. *Adjust* the [multi-store configuration](/docs/reference/stratus/control-panels/application-panel/multistore/ "Multistore Control Panel"/) to match the live domains.
7. *Disable* maintenance mode on the STRATUS environment, **leaving maintenance mode on the old host**.
8. *Verify* the new site.

## Troubleshooting and Final Check

* Repeat the initial testing for basic environment functionality
* Test the checkout
* Check all caches and performance settings, review [Magento Performance FAQ](/docs/reference/stratus/guides/optimizations/magento-configuration-and-optimization/ "Optimizing Magento"/).
* Contact Webscale STRATUS Support if needed.
---
# Stratus Guides - STRATUS CLI
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/stratus-cli/
Description: The Webscale STRATUS Command Line Interface (CLI) is available to run cache clearing and other commands for easier management of a deployment.


> The following commands are accessible via SSH access. See the [SSH > Info](/docs/reference/stratus/control-panels/ssh-panel/info/) Webscale STRATUS Control panel for access parameters.

## Help

*Run* `/usr/share/stratus/cli help` for a list of viewable commands with descriptions.

## Command Format

CLI commands are entered as `/usr/share/stratus/cli <command>`. For example, to use the command `database.config` *run* `/usr/share/stratus/cli database.config`

## Common Commands

### `autoscaling.reinit` 
If autoscaling is enabled, this command will issue a redeploy of PHP-FPM services and update the code copied out to the various physical nodes. This is a rolling redeployment for zero environment downtime and minimal site downtime. The command executes asynchronously and will return before all the redeployment is completed. It is for [legacy deploys](/docs/reference/stratus/guides/webscale-stratus/deploy-to-stratus/) only. This command should not be used if you are using [Zero-Downtime Deployment](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/)

> **NOTE:** On average a redeployment takes several seconds or more depending on the size of the code base deployed.

### `cache.all.clear`
Except for Redis or Memcache sessions, this command clears all other caches, including Cloudfront, PHP OpCache, Redis FPC, Redis Config, and Varnish (if enabled).

> **NOTE:** CloudFront may take up to 15 minutes to clear all edge nodes.

### `cache.opcache.flush`
Flushes only the PHP OpCache.

### `cache.cloudfront.invalidate`
Clears  the CloudFront CDN cache, and can take up to 15 minutes to complete.

### `cache.redis.clear`
Flushes Redis. Equivalent to running `redis-cli -h redis flushall`.

### `cache.varnish.clear`
Purges Varnish cache.

### `database.config`
Returns the database credentials in JSON format.

### `magento.install`
Installs the latest Magento 2 code base.

> **NOTE:** this will completely delete all data and replace the code base.

### `php.options.add`
Adds PHP option values, such as "memory_limit." For example, to set the PHP memory limit to 4,096 megabytes, *run* `php.options.add memory_limit=4096M`.

### `php.options.remove`
Removes PHP option values previously added using `php.options.add`.

### `php.options.list`
Lists current PHP settings

### `nginx.update`
Reloads nginx configs gracefully

### `zerodowntime.init`
Prepare a deployment for a B/G (Blue/Green) switch with [ZDD](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/ "Zero-Downtime Deploys on Webscale STRATUS"/)

### `zerodowntime.switch`
Perform B/G (Blue/Green) switch with [ZDD](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/ "Zero-Downtime Deploys on Webscale STRATUS"/)

### `crons.stop`
Stops crons

### `crons.stop.gracefully`
Stops crons gracefully (waits 60 seconds for completion before stopping the cron)

### `crons.start`
Starts crons

See also [Zero-Downtime Deploys on STRATUS](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/ "Zero-Downtime Deploys on Webscale STRATUS"/).

&nbsp;
---
# Stratus Guides - Default Cron Configurations
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/default-crons/
Description: For Magento to run properly a number of recommended cron tasks must be in place.


Use the following as a guide for configuring production environments in the Webscale STRATUS [**Cron > Schedule**](/docs/reference/stratus/control-panels/cron-panel/schedule/) panel.

## Magento 1

Magento 1 requires `cron.sh` to run every minute to update and execute it's internal schedule.  On a default Webscale STRATUS environment that configuration would be:

{{< figure src="/images/stratus/img/articles/m1cron.png" alt="M1 Cron-62" >}}

To configure the cron using crontab via shell access, *enter*:

	* * * * * /bin/bash /srv/public_html/cron.sh >> /srv/public_html/var/log/cron.log 2>&1

## Magento 2

Magento 2.x requires three cron tasks. By default, these are **already configured on every new Webscale STRATUS environment**. If the document or web roots are changed, the tasks will need updated to show the correct file paths.

To enter these cron tasks using crontab, use:

  * **Cron 1** — `/usr/local/bin/php /srv/public_html/bin/magento cron:run >> /srv/public_html/var/log/cron.log`
  * **Cron 2** — `/usr/local/bin/php /srv/public_html/update/cron.php >> /srv/public_html/var/log/cron.log`
  * **Cron 3** — `/usr/local/bin/php /srv/public_html/update/cron.php >> /srv/public_html/var/log/cron.log`
---
# Stratus Guides - New Relic
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/newrelic-on-stratus/
Description: New Relic’s PHP APM can be used on Webscale STRATUS to get transaction traces and fine grained data about what calls are slow. A basic version of New Relic is installed by default on all Webscale STRATUS environments.


When purchasing or obtaining a New Relic license, please choose the option "Self-Hosted Environment." Stratus currently supports New Relic APM only. (NRAL KEYS) Once a license key is received, open a support ticket to have the key added to the Webscale STRATUS environment.

> Adding your own license will populate trace data for any transactions over 2 seconds to your New Relic account, so you may need to wait 24 hours after adding the license to analyze any findings.  
---
# Stratus Guides - Cloudflare DNS Setup
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/cloudflare-and-stratus/
Description: Instructions on how to configure the CloudFlare DNS to use with Webscale STRATUS.


> **NOTE:** when using Cloudflare for DNS, Webscale cannot assign or install a *Let's Encrypt* certificate; LE certficates can only be installed when using the Webscale Route 53 nameservers. Furthermore, certificates issued and signed by Cloudflare cannot be installed on Webscale STRATUS. Certificates must be issued by a publicly trusted Certificate Authority (CA), such as [ACM](https://aws.amazon.com/certificate-manager/private-certificate-authority/ "AWS Certificate Manager") or those listed by the [Mozilla Foundation](https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport "Other CA issuers"). For more information, see ["Continually Enhancing Domain Security on Amazon CloudFront"](https://aws.amazon.com/blogs/networking-and-content-delivery/continually-enhancing-domain-security-on-amazon-cloudfront/).

The initial setup wizard for Cloudflare will prompt to point A records instead of a CNAME. This is not an ideal setup because IPs can change and will be different depending on geographical location. Cloudflare can be allowed to pull records automatically since it will also pull the needed records for Amazon SES. Cloudflare will automatically apply CNAME flattening.

Remove the A records and change the DNS to point to the cloudfront URL for your domain. You can find this under the **DNS** Admin panel in stratus.

![Screenshot](/images/stratus/img/articles/cfstratuspanel.png)

## Sample Cloudflare DNS Setup

![Screenshot](/images/stratus/img/articles/cfdns.png)

Changing nameservers should not cause any downtime if the domain is currently pointed to stratus. However, as a precaution, proceed during off-peak hours. If the domain is not currently pointed to stratus, DNS changes can take up to 24hrs to propagate.

## Cloudflare Settings

Under **SSL > Overview**, make sure the setting is set to *FULL*.

![Screenshot](/images/stratus/img/articles/cffull.png)

Under **SSL > Edge Certificates**, make sure **Always Use HTTPS** is set to *On*.

![Screenshot](/images/stratus/img/articles/cfhttps.png)

## Cloudflare Proxy

Once the environment is behind Cloudflare, the proxy portion can be turned off any time under the DNS tab in the Cloudflare account by turning the orange cloud to a grey cloud (by clicking it).

**Proxied** example:

![Screenshot](/images/stratus/img/articles/cfproxy.png)

**Not Proxied** example:

![Screenshot](/images/stratus/img/articles/cfproxyno.png)

## Nginx Includes

By default RealIP snippets are in Sratus NGINX conf for Cloudflare IPs. This will ensure that your logs will show the real customer's IP and not a Cloudflare Proxy IP.
[Cloudflare Article](https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs-Logging-visitor-IP-addresses "Restoring original vistor IPs")

## Whitelisting Validation

It is important that an additional step be taken to whitelist the STRATUS environment in Cloudflare. Otherwise, Google Analytics validation will fail if you choose to use it for session counting.

See [Whitelisting Validation for Cloudflare](/docs/reference/stratus/guides/security/using-external-services/#whitelisting-validation-for-cloudflare "Instructions for whitelisting STRATUS in Cloudflare"/) for instructions.
---
# Stratus Guides - Backup Strategies
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/backup-strategies/
Description: If you have your own AWS, Google Cloud or Backblaze account you can send files and backups directly to them.


## Backup to Amazon S3 Bucket


The AWS CLI comes preinstalled on Stratus. *Run* `aws configure` and follow the prompts entering the appropriate region and [access key](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html) for your AWS account.

Example:
```
$ aws configure
AWS Access Key ID [None]: ABCDEFGHIJKLMNOPQRSTUVWXYZ
AWS Secret Access Key [None]: FaK3S3Cr3tAcc3SSK3yF0rFun
Default region name [None]: us-east-1
Default output format [None]: text
```

*Run* `aws s3 ls` to show your existing buckets and manage other AWS resources.

For example, a new backup called **my-magento-backup** can be created with:  

	$ aws s3 mb s3://my-magento-backup
	make_bucket: my-magento-backup
	$ aws s3 ls
	2019-03-19 13:23:50 my-magento-backup

> You can created backups in Magento 2 with the [built-in backup system](https://devdocs.magento.com/guides/v2.3/install-gde/install/cli/install-cli-backup.html "Magento Backup System").

To create a database dump and a tar of the web root:

	$n98-magerun2 db:dump s3_backup.sql
	$tar -zcvf s3_backup_3_19_2019.tar.gz /srv/public_html/

> Archiving a Magento store can take a long time.

To upload the backup to AWS:

	$ aws s3 ls
	2019-03-19 13:23:50 my-magento-backup
	$ aws s3 cp s3_backup_3_19_2019.tar.gz s3://my-magento-backup
	upload: ./s3_backup_3_19_2019.tar.gz to s3://my-magento-backup/s3_backup_3_19_2019.tar.gz

The file will upload with progress details.Once uploaded, the archive can be seen within the bucket in the AWS Console or web interface.
{{< figure src="/images/stratus/img/articles/s3_backup.png" alt="S3 Bucket" >}}

> Learn more about S3 commands [from Amazon](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-s3-commands.html "AWS S3 Commands").

A script can be set to create a backup and upload to S3. Then a cron can be set to automatically run the script.

	#!/bin/bash
	#S3 Backup Example

	date="$(date "+%m-%d-%Y")"
	bucket_name="my-magento-backup"
	magento_root="/srv/public_html"

	#create databasedump
	echo "Creating database dump..."
	/usr/local/bin/n98-magerun2 --root-dir=$magento_root db:dump db-backup-$date.sql

	#create archive of webroot, excluding var
	echo "Creating tar archive of files and database dump..."
	tar --exclude=/srv/public_html/var/* -zcf $date-backup.tar.gz /srv/public_html/

	#upload to s3
	echo "Uploading to S3..."
	aws s3 cp $date-backup.tar.gz s3://my-magento-backup

	#clean up
	echo "Removing local files and cleaning up..."
	rm $date-backup.tar.gz
	rm $magento_root/db-backup-$date.sql

	echo "Done!"

The above would output:

	$ ./backup.sh
	Creating database dump...

	  Dump MySQL Database

	Start dumping database db_cded1u2ypqu to file db-backup-03-19-2019.sql
	Finished
	Creating tar archive of files and database dump...
	tar: Removing leading `/' from member names
	Uploading to S3...
	upload: ./03-19-2019-backup.tar.gz to s3://my-magento-backup/03-19-2019-backup.tar.gz
	Removing local files and cleaning up...
	Done!

## Dropbox backups

The official Dropbox CLI utility from Dropbox is not currently supported on Webscale STRATUS. A [3rd party script][9] may be used to push files to a Dropbox folder with the proper access tokens.

## Backup to Google Cloud

To backup a Webscale STRATUS environment to Google Cloud, an [account must be created](https://accounts.google.com/signup). Next, create a project from the [Google Cloud Console](https://console.cloud.google.com/project). As an example: my-backups-256118.

*gsutil* is used for this tutorial. gsutil is a Python application that accesses Google Cloud Storage from the command line.

1. Begin by *downloading* the files from Google. *Extract* them locally.

		$ wget https://storage.googleapis.com/pub/gsutil.tar.gz
		$ tar -zxvf gsutil.tar.gz

2. Next, configure gsutil to connect to Google.

		$ ./gsutil/gsutil config
		This command will create a boto config file at /srv/.boto containing
		your credentials, based on your responses to the following questions.
		Please navigate your browser to the following URL:
		https://accounts.google.com/o/oauth2/auth?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&client_id=909320924072.apps.googleusercontent.com&access_type=offline
		In your browser you should see a page that requests you to authorize access to Google Cloud Platform APIs and Services on your behalf. After you approve, an authorization code will be displayed.

		Enter the authorization code: [Authorization Code]

		Please navigate your browser to https://cloud.google.com/console#/project,
		then find the project you will use, and copy the Project ID string from the
		second column. Older projects do not have Project ID strings. For such projects,
		click the project and then copy the Project Number listed under that project.

		What is your project-id? [Project ID]

		gsutil developers rely on user feedback to make improvements to the
		tool. Would you like to send anonymous usage statistics to help
		improve gsutil? [y/N] y

		Boto config file "/srv/.boto" created. If you need to use a proxy to
		access the Internet please see the instructions in that file.

3. Next, *create* a bucket. Buckets need to be a unique name as they share a global naming scheme at Google. Standard storage is used in this example. Google has [different storage types](https://cloud.google.com/storage/docs/storage-classes).

		$ ./gsutil/gsutil mb -c standard -l US -p my-backups-256118 gs://mark-stratus-backups
		Creating gs://[bucket-name]...

4. *Create* a manual backup by switching to the document root, dumping a copy of the database, and then creating an archive;

		$ cd public_html/
		~/public_html$ n98-magerun2 db:dump backup.sql
		~/public_html$ tar -zcvf backup_10_16_2019.tar.gz /srv/public_html/

5. Once archived, *copy* to Google:

		$ ./gsutil/gsutil cp /srv/public_html/backup_10_16_2019.tar.gz gs://[bucket-name]
		Copying file:///srv/public_html/[backup-name].tar.gz [Content-Type=application/x-tar]...
		\ [1 files][126.1 MiB/126.1 MiB]                                                
		Operation completed over 1 objects/126.1 MiB.                                    
		~$ ./gsutil/gsutil ls -l gs://[bucket-name]
		 132217623  2019-10-16T18:52:52Z  gs://[bucket-name]/[backup-name].tar.gz
		TOTAL: 1 objects, 132217623 bytes (126.09 MiB)

A script can be set that creates a backup and uploads it to Google. Then a cron can be set to automatically run the script.

	#!/bin/bash
	#Google Cloud Backup Example

	date="$(date "+%m-%d-%Y")"
	bucket_name="mark-stratus-backups"
	magento_root="/srv/public_html"

	#create database dump
	echo "Creating database dump..."
	/usr/local/bin/n98-magerun2 --root-dir=$magento_root db:dump db-backup-$date.sql

	#create archive of webroot, excluding var
	echo "Creating tar archive of files and database dump..."
	tar --exclude=/srv/public_html/var/* -zcf $date-backup.tar.gz /srv/public_html/

	#upload to Google
	echo "Uploading to Google..."
	./gsutil/gsutil cp $date-backup.tar.gz gs://$bucket_name

	#clean up
	echo "Removing local files and cleaning up..."
	rm $date-backup.tar.gz
	rm $magento_root/db-backup-$date.sql

	echo "Done!"

## Backup to Backblaze

Backing up Webscale STRATUS to Backblaze B2 can be performed using a tool called Restic.

1. *Create* a [Backblaze account](https://www.backblaze.com/b2/sign-up.html).

2. Create a new bucket. Note the Bucket Unique Name for later:

	![Screenshot](/images/stratus/img/articles/bb-bucket.jpg)

3. *Go to* the App Keys section and *add* a new key. The key can be created with access to any bucket or can be optionally restricted to access to a specific bucket. Noe the *keyID* and *applicationKey* for later use.

	![Screenshot2](/images/stratus/img/articles/bb-key.jpg)

	![Screenshot3](/images/stratus/img/articles/bb-keyb.jpg)

4. *Go to* Github to get the [latest pre-compiled binary for Restic](https://github.com/restic/restic/releases).

	* *Download* and *extract* the code into `/srv`.
	* *Rename* the program to "restic".
	* *Grant* the file execution permission.

			$ wget https://github.com/restic/restic/releases/download/v0.9.6/restic_0.9.6_linux_amd64.bz2
			$ bzip2 -d restic_0.9.6_linux_amd64.bz2
			$ mv restic_0.9.6_linux_amd64 restic                   
			$ chmod u+x restic

5. *Create* a file called restic-pw.txt which will store a random string.

		$ export B2_ACCOUNT_ID="[keyID]"
		$ export B2_ACCOUNT_KEY="[applicationKey]"
		$ export RESTIC_REPOSITORY="b2:magemojo-b2-kb"
		$ export RESTIC_PASSWORD_FILE="restic-pw.txt"

6. *Initialize* the new bucket:

		$ ./restic -r b2:magemojo-b2-kb init
		created restic repository b44062684d at b2:magemojo-b2-kb

		Please note that knowledge of your password is required to access
		the repository. Losing your password means that your data is
		irrecoverably lost.

7. Perform a backup. On a clean Magento 2 installation, this takes about 2 minutes to perform.

		$ ./restic -r b2:magemojo-b2-kb backup public_html/
		repository b4406268 opened successfully, password is correct
		created new cache in /srv/.cache/restic

		Files:       74683 new,     0 changed,     0 unmodified
		Dirs:            0 new,     0 changed,     0 unmodified
		Added to the repo: 402.722 MiB

		processed 74683 files, 507.124 MiB in 1:40
		snapshot f0263a11 saved

If the same command is run again, Restic will create another snapshot of the data. Restic uses de-duplication, thus the next backups will always be faster as only files that are new or have been modified since the last snapshot are sent to B2.

All snapshots can be ween with the following command:

	$ ./restic -r b2:magemojo-b2-kb snapshots
	repository b4406268 opened successfully, password is correct
	ID        Time                 Host                     Tags        Paths
	------------------------------------------------------------------------------------
	f0263a11  2019-12-18 19:00:06  hostname                /srv/public_html
	------------------------------------------------------------------------------------
	1 snapshots

To a the specific snapshot  use the -t flag to specify a restore location;

	$ ./restic -r b2:magemojo-b2-kb restore f0263a11 -t /tmp/restore
	repository b4406268 opened successfully, password is correct
	restoring <Snapshot f0263a11 of [/srv/public_html] at 2019-12-18 19:00:06.135398979 +0000 UTC by username> to /tmp/restore

Next, a script can be set for a backup cron job.

	#!/bin/bash
	#Backblaze B2 Backup Example

	magento_root="/srv/public_html"

	export B2_ACCOUNT_ID="[keyID]"
	export B2_ACCOUNT_KEY="[applicationKey]"
	export RESTIC_REPOSITORY="b2:magemojo-b2-kb"
	export RESTIC_PASSWORD_FILE="restic-pw.txt"

	#create database dump
	echo "Creating database dump..."
	/usr/local/bin/n98-magerun2 --root-dir=$magento_root db:dump db-backup.sql

	#upload to Backblaze
	echo "Uploading to Backblaze B2..."
	./restic -r $RESTIC_REPOSITORY backup $magento_root

	#clean up
	echo "Removing local db backup..."
	rm $magento_root/db-backup.sql

	echo "Done!"
---
# Stratus - General Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/
Description: Backup Strategies | Debugging Cron | Other CDNs | Rotating Magento Logs | Using Symlinks | Blackfire.io | Xdebug | Configuring RabbitMQ | Node version manager | Updating Base URLs | Multistore Configuration

---
# Stratus Guides - Debugging Cron Errors
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/debugging-cron-tasks/
Description: Crons can be difficult to debug, even on a standard dedicated server. Cron tasks on the common Linux server log their execution to a file, typically cron.log in /var/log. On Webscale STRATUS, this activity is not logged directly. Cron logs are typically useless other than to know the task attempted to run; a cron.log file does not tell you if the command ran correctly.


> **NOTE**: All Magento 2 stores hosted on Webscale STRATUS are required to have installed the [MageMojo Cron extension](/docs/reference/stratus/guides/magento-2/magemojo-cron/ "MageMojo Magento 2 Cron extension information"/). This extension helps prevent many of the cron issues inherent with Magento 2.

## Debugging Magento Cron Tasks

Magento has its own default cron that runs and executes internal jobs and schedules. The best way to confirm these are running is using the [n98-magerun(2) utility][1].

To confirm any jobs have ran recently, do the following:

  1. *Connect* to the Webscale STRATUS environment via [SSH](/docs/reference/stratus/control-panels/ssh-panel/info/ "Learn more about SSH access"/).
  2. *Change* to the Magento root directory.
  3. *Run* `n98-magerun2 sys:cron:history | head -25`
  (For Magento 1.x, use `n98-magerun sys:cron:history | head -25`)

Below is an example output from this command:

	bash
	Last executed jobs
	Times shown in America/Los_Angeles
	+-----------------------------------------------+---------+---------------------+
	| Job                                           | Status  | Finished            |
	+-----------------------------------------------+---------+---------------------+
	| consumers_runner                              | success | 2021-03-01 07:54:07 |
	| indexer_reindex_all_invalid                   | success | 2021-03-01 07:54:07 |
	| indexer_update_all_views                      | success | 2021-03-01 07:54:07 |
	| sales_send_order_shipment_emails              | success | 2021-03-01 07:54:06 |
	| sales_send_order_creditmemo_emails            | success | 2021-03-01 07:54:06 |
	| magento_newrelicreporting_cron                | success | 2021-03-01 07:54:06 |
	| bulk_cleanup                                  | success | 2021-03-01 07:54:06 |
	| catalog_product_outdated_price_values_cleanup | success | 2021-03-01 07:54:05 |
	| catalog_product_frontend_actions_flush        | success | 2021-03-01 07:54:05 |
	| outdated_authentication_failures_cleanup      | success | 2021-03-01 07:54:05 |
	| sales_grid_order_async_insert                 | success | 2021-03-01 07:54:05 |
	| sales_grid_order_invoice_async_insert         | success | 2021-03-01 07:54:05 |
	| sales_grid_order_shipment_async_insert        | success | 2021-03-01 07:54:05 |
	| sales_grid_order_creditmemo_async_insert      | success | 2021-03-01 07:54:05 |
	| sales_send_order_emails                       | success | 2021-03-01 07:54:05 |
	| sales_send_order_invoice_emails               | success | 2021-03-01 07:54:05 |

In this example, the times show jobs that recently ran, which indicates that the cron tasks appear to be running at proper intervals. If a gap of time beyond the expected interval span exists, it would indicate that one or more tasks did not operate properly.

If a time gap does exist, confirm that:

* The cron commands and paths listed in the Webscale STRATUS [Cron Schedule](/docs/reference/stratus/control-panels/cron-panel/schedule/ "Cron Schedule Conrol Panel"/) panel are correct.
* Check any output if the tasks are directing the cron commands to a file.

## Running a Specific Magento Cron Task

Many time the failure of a cron task is due to a single cronjob failing and stopping others from completing. To run a single cronjob:

1. *Connect* to the Webscale STRATUS environment via [SSH](/docs/reference/stratus/control-panels/ssh-panel/info/ "Learn more about SSH access"/).
2. *Change* to the Magento root directory.
3. *Run* `n98-magerun2 sys:cron:run`
(For Magento 1.x, use `n98-magerun sys:cron:run`)

		bash
		~/public_html$ n98-magerun2 sys:cron:run
		  Cronjob
		[1] aggregate_sales_report_bestsellers_data
		[2] aggregate_sales_report_coupons_data
		[3] aggregate_sales_report_invoiced_data
		[4] aggregate_sales_report_order_data
		[5] aggregate_sales_report_refunded_data
		[6] aggregate_sales_report_shipment_data
		[7] aggregate_sales_report_tax_data
		[8] amazon_payments_process_queued_refunds
		[9] analytics_collect_data
		[10] analytics_subscribe
		[11] analytics_update
		[12] backend_clean_cache
		[13] bulk_cleanup
		[14] captcha_delete_expired_imag

4. *Enter* the job number (in brackets) to run a specific job. The output will report either "success" or "failure," as well as other errors which can help diagnose the issue.

## Restarting stopped crons

1. *Connect* to the STRATUS environment via [SSH](/docs/reference/stratus/control-panels/ssh-panel/info/ "Learn more about SSH access"/).
2. *Run* [/usr/share/stratus/cli crons.stop][6]
7. *Run* `pkill -u www -f 'cron|consumer'`
3. *Change* to the Magento root directory.
4. *Run* `rm -rf var/cron/*` (This deletes the schedule files in var/cron/)
5. *Run* `n98-magerun2 db:console` (This will log you in to MySQL)
6. *Run* `delete from cron_schedule;`(This deletes the cron schedule)
8. *Run* [/usr/share/stratus/cli crons.start][7]

## Testing Crons on a Development Environment

Crons are not set to run in development Environments of a Magento store. However, you can still test your crons using the [Magento CLI commands](/docs/reference/stratus/control-panels/application-panel/cli-commands/ "Magento CLI Commands Control Panel"/).
---
# Stratus Guides - Other CDNs
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/other-cdns/
Description: This article is in reference to proxy services like CloudFlare, Sucuri, Fastly, and Section.io.


When using other proxy services you introduce routing complexities. A request to an environment will first route through your proxy provider’s edge location, then to the CloudFront edge location and on to the AWS home region.

In these cases, STRATUS has no control of the full request flow. Support becomes more difficult due to a lost of visibility and diagnostics for systems outside of Webscale STRATUS.

In some cases, these services develop technical issues of their own, from routing/request failures or customer misconfigurations. Adding the additional proxy increases latency on every request to your environment.

It is not recommended to use varnish on the CDN edge. Varnish at the edge is only	 delivering the tiny compressed html page which might reduce speeds by mere milleseconds, yet add additional issues, such as:

* additional latency for everyone you introduce
* additional points of failure
* another service to learn and support
* extra monthly fees.

To use Cloudflare as a proxy service, review these [instructions](/docs/reference/stratus/guides/webscale-stratus/cloudflare-and-stratus/).
---
# Stratus Guides - Rotating Magento Logs
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/logrotate-magento-logs/
Description: Rotating logs can help prevent log files from becoming too large and unwieldy.




To setup *Logrotate* to automatically rotate Magento logs:

1. *Create* a directory outside of the webroot to hold the config files:

		mkdir /srv/etc/
		mkdir /srv/etc/logrotate

2. *Create* a `logrotate.conf` file with the following content:

		/srv/public_html/var/log/*.log {
		    su magemojo magemojo
		    daily
		    missingok
		    rotate 30
		    compress
		    delaycompress
		    notifempty
		    olddir /srv/scaled/var/log/old/
		}

	* **su magemojo magemojo** — Ensures that permissions stay correct
	* **daily** – Run once a day at time set by cron job
	* **missingok** — Don't panic if empty
	* **rotate 30** — Retain for 30 days
	* **compress** — Compress 2nd most recent file
	* **delaycompress** — Do not compress newest rotated log
	* **notifempty** — Do not rotate empty files

4. *Add* a [cron job](/docs/reference/stratus/control-panels/cron-panel/schedule/ "Cron Schedule Control Panel"/) to run once a day at the correct time:

	`/usr/sbin/logrotate -s /srv/etc/logrotate/logrotate.state /srv/etc/logrotate/logrotate.conf`
---
# Stratus Guides - Using Symlinks
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/using-symlinks/
Description: Due to auto-scaling requirements, when using symlinks do not use relative paths. All paths must be absolute.



Good Example:
```
env.php -> /srv/shared/app/etc/env.php
```

Bad Example:
```
env.php -> ../../../../env.php
```
---
# Stratus Guides - Blackfire.io
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/using-blackfire/
Description: [Blackfire.io](https://blackfire.io/ "Blackfire website") is a paid PHP profiling tool. Unlike XDebug, it can be left on without impacting site performance. It is also considered easier to use than XDebug for performance checks. However, it cannot act as powerful a debugger as XDebug.






> **NOTE:** XDebug and Blackfire can never be used together.

1. *Log into* a [Blackfire.io](https://blackfire.io/ "Blackfire website") account.
2. *Set up* an environment or profile to obtain a *Server ID* and *Server Token*.
To get started, first make sure you have an account with Blackfire.io. Set up an environment or profile so that you have a Server ID and Server Token.
3. *Go to* the **[PHP > Blackfire][2]** Admin panel.
4. *Enter* the [information as indicated](/docs/reference/stratus/control-panels/php-panel/blackfire/ "Blackfire Control Panel"/).

{{< figure src="/images/stratus/img/articles/blackfire_config.png" alt="config-75" >}}

Using the [Chrome or Firefox](https://blackfire.io/docs/integrations/browsers/index "Blackfire browser extensions") browser extensions, start profiling the Webscale STRATUS site direct from a browser.

## Update Varnish

In order for Blackfire to run with Varnish (if enabled), the following code needs to be added to Varnish VCL *inside* the sub *vcl_rcv* function:

	if (req.esi_level > 0) {
	    # ESI request should not be included in the profile.
	    # Instead you should profile them separately, each one
	    # in their dedicated profile.
	    # Removing the Blackfire header avoids to trigger the profiling.
	    # Not returning let it go trough your usual workflow as a regular
	    # ESI request without distinction.

	    unset req.http.X-Blackfire-Query;
	}

	# If it's a Blackfire query and the client is authorized
	# just pass directly to the application.

	if (req.http.X-Blackfire-Query) {
	    return (pass);
	}
---
# Stratus Guides - Using Xdebug
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/using-xdebug/
Description: Xdebug is default configured on Webscale STRATUS for debugging your code. It is highly advised not to use Xdebug on a production environment unless absolutely necessary as it will drastically slow down the site.


> While a powerful tool, Xdebug can drastically slow down a store if used in production, even when not actively tracing or profiling anything. It is highly advised to **not** use Xdebug on a Production environment unless absolutely necessary.

Xdebug has a variety of settings. By default Xdebug is configured in Webscale STRATUS to cover most situations. There are three ways to use Xdebug:

* **Profiling** — outputs cachegrind files on the Webscale STRATUS file system to evaluate request performance
* **Tracing** — outputs trace files on the file system with full output of all function calls with function processing times
* **Debug** — connects a local IDE via SSH tunnel on Webscale STRATUS to step through code when called via browser request

## Setup

1. *Install* the [Chrome extension](https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc?hl=en "Chrome XDebug extension") to trigger the profiling and tracing in Xdebug.

2. If [Varnish](/docs/reference/stratus/control-panels/varnish-panel/info/ "Varnish Control Panel"/) is running, *disable* it.

3. *Enable* Xdebug in the **[PHP > Xdebug][2]** Admin panel.

Before enabling Xdebug, set a trace and profiler value, along with a IDE key. The IDE key is not *strictly* necessary on STRATUS. The trace and profiler values will be used by the XDebug helper extension to trigger cachegrind or tracefile generation.

Once the profile values are set, click *Update*. The site will go down for a minute or two while PHP is reloaded with XDebug enabled. If Blackfire is enabled, a warning will be generated.

> **NOTE: ** Blackfire and XDebug cannot and should not be enabled at the same time.

XDebug is now enabled and ready for use. If XDebug Helper is installed, edit the option for the extension to match what you set in your Webscale STRATUS panel.

{{< figure src="/images/stratus/img/articles/xdebug_helper.png" alt="helper-75" >}}

## Tracing and Profiling

With XDebug helper, click the debug icon and choose either Profile or Trace from the available modes. Then load any page on the site to be diagnosed.

After a longer than normal page load, check the filesystem on the Webscale STRATUS environment. There will be a directory called `xdebug` in `/srv/`.

Depending on the option chosen in the XDebug helper, there will be either a *cachegrind.out.(xxxx)* file or a *trace.(xxxx).(xxxx).xt* file. Cachegrind files can be viewed with tools like KCacheGrind or WinCacheGrind and are profiles of the page request. The .xt files are raw text showing the series of function calls made in the web request.

## Remote Debugging with Breakpoints

**Note** the examples below use PHP Storm and VS Code, both common IDEs. If using another IDE, it is likely the settings here will be similar. There may also be other plugins and settings to use in either IDE.

### VS Code

Setup:

1. *Install* the [PHP Debug Plugin](https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug)
2. *Open* VS Code to a copy of the Magento site code

3. *Configure* the PHP Debug Plugin, this simple snippet should be in the `launch.json` file:

		{
		    "version": "0.2.0",
		    "configurations": [
		        {
		            "name": "Listen for XDebug",
		            "type": "php",
		            "request": "launch",
		            "port": 9000,
		            "pathMappings": {
		                "/srv/public_html/pub/": "${workspaceRoot}",
		              }
		        }
		    ]
		}

4. *Change* the path mapping to suit. Add a breakpoint somewhere in your code.  Presumably on code you know will be executed on your request.

5. *Open* an SSH tunnel to your environment with parameters:

		ssh -p <stratus_port> <username>@<hostname> -R :9001:127.0.0.1:9000

6. *Click* the bug Icon in VS Code to Debug and Run.

	{{< figure src="/images/stratus/img/articles/debug_and_run.png" alt="debug-75" >}}

7. *Request* a page on the site for debugging, with a link such as:

		https://yoursite.com/test.php?XDEBUG_SESSION_START=1

The query string will trigger XDebug to begin debugging, and the output will appear in the **variables** column in the left side in XDebug. *Use* the VS Code debug interface to continue stepping through your code.

### PhpStorm

The JetBrains IDE costs money and is very powerful, yet setup is a breeze. Similar to VS Code, an SSH tunnel is still required.

1. Open the code base in PhpStorm

2. *Press* **Ctrl-Alt-S** to open the PhpStorm settings menu. *Go to* **Languages and Frameworks -> PHP -> Debug**.

	{{< figure src="/images/stratus/img/articles/php_storm_settings.png" alt="settings-75" >}}

3. *Set* the XDebug section as shown above.

4. *Open* an SSH tunnel to the Webscale STRATUS environment.

		ssh -p <stratus_port> <username>@<hostname> -R :9001:127.0.0.1:9000

5. In the Magento code base/project, *set* breakpoints in PhpStorm.

6. *Enable* the XDebug listener via the **Phone icon** in the top right of the editor, or in the Settings menu under the Debug settings of PHP there is a link, *Start Listening*.

7. *Request* a page on your site for debugging, with a link such as:

		https://yoursite.com/test.php?XDEBUG_SESSION_START=1

A prompt will pop-up showing that debugging is active.
---
# Stratus Guides - Configuring RabbitMQ
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/configuring-rabbitmq/
Description: The RabbitMQ management plugins are enabled in Webscale STRATUS, and can be accessed using the correction configurations. When possible, Webscale recommends using RabbitMQ as the broker instead of MySQL.




## Consumers

To see a list of available consumers that you can set to run, use:

	php bin/magento queue:consumers:list

> Please note the following:
* In a [production environment](/docs/reference/stratus/about-webscale-stratus/environment-types/#production-environments/) the host will be *rabbitmq*
* In a [development environment](/docs/reference/stratus/about-webscale-stratus/environment-types/#development-environments/) the host will be *0.0.0.0*, unless Autoscaling is enabled then the host will remain *rabbitmq*.

Below is an example configuration of the `env.php` file.

	'cron_consumers_runner' => [
	        'cron_run' => true,
	        'max_messages' => 0,
	        'consumers' => [
	            'async.operations.all',
	            'codegeneratorProcessor',
	            'product_action_attribute.update',
	            'product_action_attribute.website.update',
	            'exportProcessor'
	        ]
	    ],
	    'queue' => [
	        'amqp' => [
	            'host' => 'rabbitmq',
	            'port' => '5672',
	            'user' => 'username',
	            'password' => 'yb2sovjbaa4atsbbn0s0ccm9uddekh6i',
	            'virtualhost' => '/',
	            'ssl' => 'false',
	            'ssl_options' => []
	        ]
	    ],

A simple one-line command to add RabbitMQ queue to env.php file is:

```
php bin/magento -q -n setup:config:set --amqp-host="rabbitmq" --amqp-port="5672" --amqp-user="username" --amqp-password="8b2sovjbgg4atsbpn0ilovemagemojo" --amqp-virtualhost="/"
```

## RabbitMQ

The [RabbitMQ message broker service](https://devdocs.magento.com/guides/v2.3/config-guide/mq/manage-message-queues.html) can be enabled in your Webscale STRATUS panel in the **[RabbitMQ > Info](/docs/reference/stratus/control-panels/rabbitmq-panel/info/)** panel.

The credentials shown in the **[RabbitMQ > Configuration](/docs/reference/stratus/guides/general/configuring-rabbitmq/)** panel may be changed, but must match the ones configured in `env.php`.

> These are only used on the *initial deploy* of RabbitMQ. If these credentials are changed after starting RabbitMQ, it will not affect the existing user.

![RabbitMQ Configuration](/images/stratus/img/articles/rabbitmq-configuration-1.png)

## Multiple_processes option

An array of key-value pairs specifying which consumer to run in how many processes. The `--multi-process` option is present in the `queue:consumers:start` command, but to run consumers with parallel processes, configure the multiple_processes option in /app/etc/env.php. Otherwise, if queue:consumers:start is called with the --multi-process option, it only works on a single thread.

Example with all Magento 2 Core Consumers added:

```
'cron_consumers_runner' => [
        'cron_run' => true,
        'max_messages' => 0,
        'consumers' => [
            'product_action_attribute.update',
            'product_action_attribute.website.update',
            'media.storage.catalog.image.resize',
            'exportProcessor',
            'inventory.source.items.cleanup',
            'inventory.mass.update',
            'inventory.reservations.cleanup',
            'inventory.reservations.update',
            'inventory.reservations.updateSalabilityStatus',
            'inventory.indexer.sourceItem',
            'inventory.indexer.stock',
            'media.content.synchronization',
            'media.gallery.renditions.update',
            'media.gallery.synchronization',
            'codegeneratorProcessor',
            'sales.rule.update.coupon.usage',
            'sales.rule.quote.trigger.recollect',
            'product_alert',
            'async.operations.all'
        ]
    ],
```

To extend with four (4) threads instead (single-threaded) for product_action_attribute.update, this is how we would convert within the env.php file:

```
'cron_consumers_runner' => [
        'cron_run' => true,
        'max_messages' => 0,
        'consumers' => [
            'product_action_attribute.update',
            'product_action_attribute.website.update',
            'media.storage.catalog.image.resize',
            'exportProcessor',
            'inventory.source.items.cleanup',
            'inventory.mass.update',
            'inventory.reservations.cleanup',
            'inventory.reservations.update',
            'inventory.reservations.updateSalabilityStatus',
            'inventory.indexer.sourceItem',
            'inventory.indexer.stock',
            'media.content.synchronization',
            'media.gallery.renditions.update',
            'media.gallery.synchronization',
            'codegeneratorProcessor',
            'sales.rule.update.coupon.usage',
            'sales.rule.quote.trigger.recollect',
            'product_alert',
            'async.operations.all'
        ],
        'multiple_processes' => [
            'product_action_attribute.update' => 4
        ]
    ],
```

On the next Cron run, you will see four (4) processes for product_action_attribute.update Consumer running instead of one. It is not recommended to run multiple consumers on a MySQL-operated queue. Starting with Magento 2.4.5 Queue Consumers are converted to RabbitMQ automatically. If you ares using a version lower than 2.4.5, please make sure you <a href="/reference/stratus/guides/magento-2/consumers-changing-broker/">install the RabbitMQ patch</a>.

## Default Broker

Starting with Magento 2.4.5 Queue Consumers are utilizing RabbitMQ automatically. Any previous versions, when possible, Webscale Stratus recommends using RabbitMQ as the broker instead of MySQL. Please read over [RabbitMQ vs MySQL](/docs/reference/stratus/guides/magento-2/consumers-changing-broker/#rabbitmq-vs-mysql/).


## RabbitMQ Advanced Usage

RabbitMQ ships with command line and other management utilities. Depending on the exact usage of RabbitMQ, these tools may be used to debug and investigate certain issues with a Magento install. To call RabbitMQ procedures from the command line use the *rabbitmqadmin* utility.

For example, to list the existing users:

	$ rabbitmqadmin --host rabbitmq -u kermit -p wakkawakka1234 list users
	+--------+--------------------------------+--------------------------------------------------+---------------+
	|  name  |       hashing_algorithm        |                  password_hash                   |     tags      |
	+--------+--------------------------------+--------------------------------------------------+---------------+
	| kermit | rabbit_password_hashing_sha256 | 7YJGqcUKDcnvFkxwMOq+4OLCZw8RrYZL5sOGTAz2vXdXkLBF | administrator |
	+--------+--------------------------------+--------------------------------------------------+---------------+

The [official RabbitMQ documentation](https://www.rabbitmq.com/management-cli.html) has various examples of how to use the *rabbitmqadmin* admin tool. On Webscale STRATUS, use the correct host and user in all your commands. As with the `env.php` configuration, the host will always be *rabbitmq* or *0.0.0.0*.

## Web Interface.

The RabbitMQ management plugins are enabled in Mojo STRATUS, and can be accessed using the correction configurations.

The Web UI is always running, but can only be accessed one of two ways:

1.  Use an SSH tunnel to expose the web interface on a local port
2.  Set up a proxy pass directive in the STRATUS Nginx configuration

### SSH Tunnel

An SSH tunnel is the most *secure* way to access the RabbitMQ UI.

1. To access the RabbitMQ UI, make sure an [SSH user](/docs/reference/stratus/control-panels/ssh-panel/users/ "SSH Users Panel"/) is configured for the Webscale STRATUS environment.
2. Via terminal, *run* the following command with the correct user/host/port information to open a tunnel:

		ssh -p <port> <user>@<ssh-endpoint>.mojostratus.io -L 15672:rabbitmq:15672

	> Change *rabbitmq* to *0.0.0.0*, if you are using autoscaling.

3. With the tunnel connected, *open* a local browser to http://localhost:15672/.

	![RabbitMQ Login Panel](/images/stratus/img/articles/rabbit_login.png "RabbitMQ Login panel")

4. *Enter* the username/password configured for RabbitMQ in your initial start-up (under **RabbitMQ -> Configuration**)

Read [the official docs](https://www.rabbitmq.com/management.html) for more details on how to use and interpret the UI..

### Nginx Proxy Pass

Although *not* recommended, an Nginx Proxy Pass may be used for quick access. It is also recommend that the location be secured by IP whitelist if the intention is to leave the UI permanently exposed.

1. *Go to* **Nginx > Includes** in the Webscale STRATUS panel.
2. Add a new location directive similar to this:

		location /yourrabbitadmin/ {
		    proxy_pass http://127.0.0.1:15672/;
		}

3. *Click* **Update** to save the changes.

The RabbitMQ UI can now be accessed at *https://mysite.com/yourrabbitadmin*.

### Resetting Data

In the **[RabbitMQ > Info](/docs/reference/stratus/control-panels/rabbitmq-panel/info/)** panel the data can be reset if needed to wipe the service clean of all data.

RabbitMQ data is persistent, similar to MySQL. Persistent data is important since some stores may use RabbitMQ to store important data like order data until it is later saved within the Magento MySQL data.
---
# Stratus Guides - Node.js Node Version Manager
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/node-js-nvm-manager/
Description: Node Version Manager (nvm) is a *version manager* for node.js, designed to be installed per-user, and invoked per-shell. __nvm__ works on any POSIX-compliant shell (sh, dash, ksh, zsh, bash), in particular on these platforms: Unix, macOS, and windows WSL.


Documentation for NVM can be found in [Github](https://github.com/nvm-sh/nvm).

## Helpful Commands

* To show available versions:

		$ nvm ls-remote

* To install a specific version:

		$ nvm install v13.10.0

* To confirm installed versions:

		$ node -v
		v14.2.0

		$ npm -v
		6.14.4

* To switch through installed versions **nvm** provides the _nvm use_ command. This works similarly to the install command.

	For example, to switch to Node.js version 13.6.0:

		$ nvm use 13.6.0

	To switch to Node.js version 12.14.1:

		$ nvm use 12.14.1

* To switch to the latest Node.js version (our system detects and always use latest one by default):

		$ nvm use node

* To switch to the latest LTS version:

		$ nvm use --lts

* To list what is already installed on server:

		$ nvm ls

> When switching to a different version, **nvm** will make the _node_ instance in your terminal symlink to the proper Node.js instance.
---
# Stratus Guides - Updating Base URLs
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/updating-base-urls/
Description: Base URLs are one of the most important parts of Magento. Learn how to change them via the MySQL database.



Base URLs are one of the most important parts of Magento and they can cause serious trouble if not entered correctly. The following is a remedy you can use to easily correct Base URLs that have been incorrectly entered.

Within the Magento Admin, Base URLs exist within the **Stores > Configuration > General > Web** panel.

  {{< figure src="/images/stratus/img/articles/updating-base-urls-1.png" alt="ssh info-2" >}}

Note that only two fields have an actual URL, the rest have placeholder variables that file in the domain automatically. This is typical of every Magento install, though some configurations have custom media/skin/js values for use with CDNs or other customizations.  

It is easy to see that setting the Base URLs incorrectly will redirect and cause a strange behavior. If you have a re-direct issue with a Magento store, first check the DNS records to make sure the DNS is set up correctly, then review the Base URLs.

## Update the URLs

While the Base URLs can always be updated by going into the Magento Admin panel, sometimes, the Base URLs are so misconfigured that accessing the backend doesn't work.

Therefore, you can access the Base URLs stored in the *core_config_data* table of your Magento database.

  1. Access your Magento install via SSH.
  2. Navigate to the Magento web root (typically, `public-html/`).
  3. Run `n98-magerun db:console` (Magento 1) or `n98-magerun2 db:console` (Magento 2).
  4. Run the query `select * from core_config_data where path like "%secure%";` (you may need to use a table prefix, if necessary). The results should appear similar to this:

  | config_id | scope   | scope_id | path                                    | value                                           |
	|-----------|---------|----------|-----------------------------------------|-------------------------------------------------|
	|         4 | default |        0 | web/unsecure/base_url                   | http://magemojo.com/                            |
	|         5 | default |        0 | web/secure/base_url                     | https://magemojo.com/                           |
	|        13 | default |        0 | web/unsecure/base_link_url              | {{unsecure_base_url}}                           |
	|        14 | default |        0 | web/unsecure/base_skin_url              | {{unsecure_base_url}}skin/                      |
	|        15 | default |        0 | web/unsecure/base_media_url             | {{unsecure_base_url}}media/                     |
	|        16 | default |        0 | web/unsecure/base_js_url                | {{unsecure_base_url}}js/                        |
	|        17 | default |        0 | web/secure/base_link_url                | {{secure_base_url}}                             |
	|        18 | default |        0 | web/secure/base_skin_url                | {{secure_base_url}}skin/                        |
	|        19 | default |        0 | web/secure/base_media_url               | {{secure_base_url}}media/                       |
	|        20 | default |        0 | web/secure/base_js_url                  | {{secure_base_url}}js/                          |
	|        21 | default |        0 | web/secure/use_in_frontend              | 1                                               |
	|        22 | default |        0 | web/secure/use_in_adminhtml             | 1                                               |
	|        23 | default |        0 | web/secure/offloader_header             | SSL_OFFLOADED                                   |
	|       464 | default |        0 | carriers/usps/gateway_secure_url        | https://secure.shippingapis.com/ShippingAPI.dll |
	|       717 | default |        0 | kbase/url_rewrite/secure_urls           | 0                                               |
	|       768 | default |        0 | google/checkout/use_secure_callback_url | 0                                               |


  5. The notable values are at the top. To change them to another value (e.g., *example.com*), run a query such as `update core_config_data set value="http://example.com" where config_id=4;`
  6. Repeat the above query and use "https" where required. If the size is a multi-store with multiple value, you may have to do this query several times.
  7. To apply the changes, *reindex* the Magento installation and *clear* the cache.
---
# Stratus Guides - Multistore Subfolder Configuration Method
URL: https://docs.webscale.com/docs/reference/stratus/guides/general/multistore-subfolders/
Description: If you would like to use the same domain, but use different stores per subfolder (such as /us, /ca, /fr, /en, etc.), you should use the subfolder method instead of the standard method for multistore configuration.


  1.	*Create* the desired folder within the `/pub/` directory in your root directory (for this example, we will use "en"). `mkdir /srv/public_html/pub/en`
  2.	*Create* the required symlinks within the new folder. Make sure they are **absolute** to prevent any issues with [autoscaling](/docs/reference/stratus/control-panels/autoscaling/ "Autoscaling control panel"/). For example:

		  cd /srv/public_html/pub/en
		  ln -s /srv/public_html/app app

  	Once completed, the `/en` directory should appear like this:

		lrwxrwxrwx  1 www www 10 Mar 23 14:07 app -> /srv/public_html/app/
		lrwxrwxrwx  1 www www 19 Mar 23 14:08 index.php -> /srv/public_html/pub/index.php
		lrwxrwxrwx  1 www www 10 Mar 23 14:08 lib -> /srv/public_html/lib/
		lrwxrwxrwx  1 www www 27 Mar 23 17:13 media -> /srv/public_html/pub/media/
		lrwxrwxrwx  1 www www 28 Mar 23 17:13 static -> /srv/public_html/pub/static/
		lrwxrwxrwx  1 www www 10 Mar 23 14:08 var -> /srv/public_html/var/

  3.	*Add* the following code to the [Nginx includes](/docs/reference/stratus/control-panels/nginx-panel/includes/ "Nginx Includes control panel"/). Adjust the subfolder name, "/en", in each occurence (7) to the actual subfolder you prefer, and the store code, "en_store_view", in the one occurence.

`location /en/ {
		index index.php index.html index.htm;
		try_files $uri $uri/ /en/index.php?$args ;
		location ~* \.php$ {
		expires off;
		fastcgi_pass php-fpm;
		fastcgi_keep_conn on;
		fastcgi_buffer_size 128k;
		fastcgi_buffers 4 256k;

		include fastcgi_params;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_param MAGE_RUN_CODE "en_store_view";
		fastcgi_param MAGE_RUN_TYPE "store";
		fastcgi_param UNIQUE_ID $connection.$connection_requests;
		fastcgi_param HTTPS $http_x_ssl_offloaded if_not_empty;

		}

		location ~ ^/en/static/version {
		        rewrite ^/en/static/(version\d*/)?(.*)$ /en/static/$2 last;
		    }

		location /en/media/ {
		    try_files $uri $uri/ /get.php$is_args$args;

		    location ~ ^/en/media/theme_customization/.*\.xml {
		        deny all;
		    }

		    location ~* \.(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ {
		        add_header Cache-Control "public";
		        add_header X-Frame-Options "SAMEORIGIN";
		        expires +1y;
		        try_files $uri $uri/ /get.php$is_args$args;
		    }
		    location ~* \.(zip|gz|gzip|bz2|csv|xml)$ {
		        add_header Cache-Control "no-store";
		        add_header X-Frame-Options "SAMEORIGIN";
		        expires    off;
		        try_files $uri $uri/ /get.php$is_args$args;
		    }
		    add_header X-Frame-Options "SAMEORIGIN";
		}

		}
---
# Stratus Guides - Magento Optimal Configuration
URL: https://docs.webscale.com/docs/reference/stratus/guides/optimizations/magento-configuration-and-optimization/
Description: Out of the box, Magento will run without issue on Webscale STRATUS, but there are a few basic configuration options you should always ensure are working.


Make sure to review the Magento configuration if there are performance issues, as it could turn out to be a simple toggle in the Magento Admin, saving valuable developer time.

> Please see our [Magento Requirements](/docs/reference/stratus/about-webscale-stratus/magento-requirements/) for a full list of items STRATUS requirements for hosting Magento stores.

## Magento 1.x Recommended Settings

  * Enable all caches (**System > Cache Management**)
  * Enable flat products and categories (**System > Configuration > Catalog > Frontend)**
  * Disable and clear the Magento compiler *(Note, the compiler does not run properly on PHP > 5.3)*
  * Enable merged CSS/JS *(be aware that this can break some sites)*
  * Install an FPC module and use Redis ([Lesti FPC](https://github.com/GordonLesti/Lesti_Fpc) is a good free option)
  * [Redis cache](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/#magento-1/)
  * [Redis sessions](/docs/reference/stratus/guides/caches-and-sessions/stratus-sessions-for-magento-1-and-2/#magento-1/)
  * Keep your log tables clean (e.g., log\_url, log\_url\_info, log\_visitor,log\_visitor\_info)
  * Set indexing mode to "manual."

## Magento 2.x Recommended Settings

  * Enable all caches.
  * Beginning with Magento 2.1, enabling flat catalogs is [NOT recommended](https://docs.magento.com/m2/ce/user_guide/catalog/catalog-flat.html) as a best practice.
  * Deploy static files (automatic with production mode deploys)
  * Enable production mode and compilation.
  * [Enable the Varnish FPC instead of the built-in FPC](/docs/reference/stratus/guides/webscale-stratus/enable-varnish-on-stratus/).
  * Use [Elasticsearch for search (2.3+ and EE)][4].
  * Disable merged CSS (can cause performance issues on some stores).
  * [Redis cache](/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/#magento-2/)
  * [Redis sessions](/docs/reference/stratus/guides/caches-and-sessions/stratus-sessions-for-magento-1-and-2/#magento-2/)
  * Set indexing mode to "Schedule."
  * [Install MageMojo Cron](/docs/reference/stratus/guides/magento-2/magemojo-cron/)

## Further optimization

For even more site speed, a skilled developer may be able to uncover additional speed gain possibilities:

  * Use New Relic's PHP APM to get transaction traces and fine grained data about which calls are slow.
  * Debug using the Magento profiler.
---
# Stratus - Optimization Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/optimizations/
Description: Magento | PWA and Headless Commerce

---
# Stratus Guides - PWA and Headless Commerce
URL: https://docs.webscale.com/docs/reference/stratus/guides/optimizations/pwa-and-headless-commerce/
Description: Webscale STRATUS actively supports new PWA technologies, including PWA Studio and Vue Storefront.


## What are PWAs?
PWAs utilize some of the latest technologies that can load blazingly fast. Along with incredible speed, PWAs (otherwise referred to as headless ecommerce) deliver a highly-customized and consistent user experience across the plethora of device types and interfaces used by online consumers.
Not to mention, PWAs compliment MageMojo’s industry defining hosting to give you websites that load in the blink of an eye. Developers can use static site generators to launch highly engaging PWA storefronts that can then be connected to ecommerce platforms on the backend.

## Benefits of PWA

Blazing Fast
PWAs utilize some of the latest technologies. This means they can load incredibly fast. Boosting your site speed is one of the easiest ways to increase user engagement & conversions. Add PWAs on top of MageMojo’s hosting and you have a powerful combination that loads websites in a flash

Cheaper and Still Effective
Want that custom app-like feel at a fraction of more traditional development costs? PWA is your solution! With a PWA you don’t need to create an iOS & Android version of your store. Get all the traditional app functionality without the separate dev resources.

Focus on Design
Being headless means that PWAs are separated from the backend of your store by design. Problems on the frontend? No worries because the backend is unaffected. And vice-versa. Feel free to make backend updates and never worry about messing up the frontend of your site. A modular and distributed site means you can rest easy.

Enhanced UX
PWAs give your users two very powerful app-like features: 1) push notifications 2) offline connectivity. Reach your customers in real time wherever they are and boost engagement rates.

Boost Your Conversions
Super speedy load times and easy-to-use app-like design means increased conversions. Guaranteed.

## Active PWA Support
MageMojo is one of the few platforms to actively support new PWA technologies, including [PWA Studio and Vue Storefront](/docs/reference/stratus/guides/pwa-configuration/). Chances are, if you are building it, we support it. Have questions about a specific build? Reach out and we’ll get your questions answered!

## Get Started
To get started, please visit [PWA and Headless Configuration](/docs/reference/stratus/guides/pwa-configuration/)
---
# Stratus - SSH & SFTP Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/ssh-and-sftp/
Description: SSH Tunnels | SFTP and FTP Access

---
# Stratus Guides - SSH Tunnels
URL: https://docs.webscale.com/docs/reference/stratus/guides/ssh-and-sftp/ssh-tunnels/
Description: To use a local MySQL manager or other application to connect to a database on Webscale STRATUS, an SSH tunnel is preferred. SSH tunnels are possible with a variety of clients. [Putty](https://putty.software/) and [OpenSSH](https://www.openssh.com/) are used in the following examples.



Before you can connect, you need several pieces of information:

  * A working [SSH login](/docs/reference/stratus/control-panels/ssh-panel/info/) to your Webscale STRATUS environment.
  * The IP address that will connect to the Webscale STRATUS MySQL (i.e., the same [IP allowed](/docs/reference/stratus/storage/whitelist/) for SSH access)
  * Your database credentials. In your Webscale STRATUS management panel, expand the **MySQL** section and click **Info** to see your database username and password

If you have the above, you can proceed.

## Creating a Tunnel with PuTTY

  1. *Open* **PuTTy** on your computer.

  {{< figure src="/images/stratus/img/articles/putty-1.png" alt="putty-92" >}}

  2. *Enter* the *SSH Host* address shown **SSH > Info**.

  3. From the left-hand tree in PuTTY, *go to* **Connection > SSH > Tunnels**.

   * **Source Port** — *Enter* "3306". If MySQL is locally using this port, enter another port number (e.g. "3307").
   * **Destination** — *Enter* myqsl with a port of "3306" (mysql:3306) This is the mysql hostname and port used by your Stratus environment.
   * *Click* **Add**.

  {{< figure src="/images/stratus/img/articles/puttytunnel.png" alt="putty tunnel-42" >}}

  4. *Click* **Open**. *Accept* the SSH if requested.
  5. *Log in* with the STRATUS SSH User credentials.

 The SSH tunnel to the remote database is now open. Connect locally using a MySQL client application. Use an IP of 127.0.0.1 and port number of 3306.

## Creating a Tunnel with OpenSSH

A secure tunnel to the Webscale STRATUS database can be created using one command line:

	ssh -p <SSHport> -L <localport>:mysql:3306 <SSHuser>@<SSHhost>

 * **SSHport** — Use the **SSH Port** found in your [SSH Info panel](/docs/reference/stratus/control-panels/ssh-panel/info/).
 * **localport** — Normally "3306", the local port used to access MySQL. If an instance of MySQL is already running locally, an alternative port may be used, such as "3307".
 * **SSHuser** — STRATUS [SSH Username](/docs/reference/stratus/control-panels/ssh-panel/users/).
 * **SSHhost** — Found in the STRATUS [SSH Info panel](/docs/reference/stratus/control-panels/ssh-panel/info/).

Using this format, a typical OpenSSH tunnel might be created using:

	ssh -p 21937 -L 3306:mysql:3306 developer_joe@ssh.5uiwe1x3ngdgg75c.mojostratus.io

After entering this into the terminal window, *enter* the STRATUS [SSH user password](/docs/reference/stratus/control-panels/ssh-panel/users/).

 {{< figure src="/images/stratus/img/articles/ssh-tunnels-2b.png" alt="putty tunnel-42" >}}

While this tunnel connection is open, open a new terminal window and connect to the Webscale STRATUS MySQL database as if it were local.

## SSH tunnels between Webscale STRATUS environments

SSH tunnels have become common between Webscale STRATUS environments for the purpose of Magento1->Magento2 data migrations. A tunnel between environments is very similar to creating a tunnel with OpenSSH, except for the following:

* Instead of SSH hostname, you must use the external IP address of the SSH host instead. For example, in the example above, for ssh.5uiwe1x3ngdgg75c.mojostratus.io, you would use the IP 3.231.50.120 instead.

 {{< figure src="/images/stratus/img/articles/ssh-dig.png" alt="putty tunnel-42" >}}

You can obtain the outgoing/SSH IP of the environment you are on via ssh with the command _curl http://ipcheck.com/_

Below is a full example of the steps needed to create an SSH tunnel between 2 environments (M1 and M2)

* Create a new SSH user on the M1 environment, allow the public SSH key & white-list the IP from the M2 environment. (curl http://ipcheck.com/)

* Create a screen on the M2 environment: screen -S tunnel

* Run the following in the screen to open the tunnel to the M1 environment:

```
ssh -p <PORT> -L 3307:mysql:3306 <USER>@<IP OF M1>
```
Example:
```
ssh -p 22000 -L 3307:mysql:3306 transfer@34.236.255.11
```

* Hit Ctrl-A-D on PC to disconnect from the screen without exiting the tunnel

You can now access both databases on the M2 environment:

Example:

```
Local m2 database: mysql -u user_abcdefghijk -p db_abcdefghijk
Remote m1 database: mysql -u user_zyxwvutsrq -p -P 3307 db_zyxwvutsrq
```
If the M2 environment is rebooted, you will need to recreate the tunnel starting at step 2 above.
---
# Stratus Guides - SFTP
URL: https://docs.webscale.com/docs/reference/stratus/guides/ssh-and-sftp/ssh-sftp/
Description: For security purposes, Webscale STRATUS does *not* allow regular File Transfer Protocol (FTP) access. Secure FTP (SFTP) access is provided.


Secure FTP (SFTP) access is provided by automatically by using the same [hostname](/docs/reference/stratus/control-panels/ssh-panel/info/ "Find your hostname and port number"/), [port](/docs/reference/stratus/control-panels/ssh-panel/info/ "Find your hostname and port number"/), [user](/docs/reference/stratus/control-panels/ssh-panel/users/ "Create and manage users"/), and [whitelist](/docs/reference/stratus/storage/whitelist/ "Create and manage allowed IPs"/) information for accessing via SSH.

> When accessing the Webscale STRATUS environment, SFTP may need to be specifically chosen as the "protocol" in the FTP access software.
---
# Stratus - DNS & SSL Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/dns-and-ssl/
Description: DNS recommendations | Sucuri Setup | Cloudflare Setup

---
# Stratus Guides - DNS Recommendations
URL: https://docs.webscale.com/docs/reference/stratus/guides/dns-and-ssl/stratus-nameservers-and-dns/
Description: In order to accommodate the auto-scaling features of Webscale STRATUS, the configuration of Domain Name Servers (DNS) is an important step in configuring a Webscale STRATUS installation.



With Webscale STRATUS, there are three options for configuring your DNS.

  1. **Preferred** — [Route 53][12] is provided with Webscale STRATUS and can host domains through the STRATUS DNS management system. Domains configured using the MageMojo Route 53 instance are pointed to a CloudFront distribution directly and will take full advanted of [CloudFront Global Edge Node](https://aws.amazon.com/cloudfront/) caching.
  2. **Acceptable** — DNS solutions that support CNAME ALIAS for flattening may be used. This method is [supported by Cloudflare](https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root) as well as Route 53. When using Cloudflare **do not use the Cloudflare CDN alongside STRATUS**.
  3. **For Temporary Use Only** — A DNS *A record* may be used to point to a particular CloudFront edge note. However, this IP is very likely to change and would require updates to A records. *This method is not supported or guaranteed to work.*

> **NOTE:** Free *Let's Encrypt SSL Certificates* provided by Webscale will only work with the **Preferred** method.

## Using the STRATUS Route 53 DNS

When a domain is added to Webscale STRATUS, a DNS zone is also created. The nameservers are then available above the DNS zone.

> **NOTE:** The nameservers will also be slightly different for every domain, since Route 53 has many different nameservers.

To retrieve the necessary nameservers for a given domain,

  1. *Open* **DNS** page within **General** section of the STRATUS Control panel.
  2. *Select* the domain in the left column.

The right panel will show the four nameservers to use to configure a domain to point to Route 53.

{{< figure src="/images/stratus/img/articles/dns-recommendations-1a.png" >}}

> It may take up to 24 hours for DNS changes to fully propagate.

## Using Third-Party Nameservers

> NOTE: Webscael cannot provide Let's Encrypt Certificates for use with non-STRATUS Route 53 namesevers.

Due to the sophistication of the Webscale STRATUS AWS platform, configuring an outside nameserver can take several important steps.

> Please note that the instructions for configuring a third-party nameserver must be all completed for Webscale STRATUS to work properly. [Support](/docs/getting-started/support/) will gladly help if asked.

  1. *Open* **DNS** page within **General** section of the STRATUS Control panel.
  2. *Select* a domain name shown in the left column. The full DNS zone will appear in the right column.
     {{< figure src="/images/stratus/img/articles/dns-recommendations-2a.png" >}}
  3. Use the items listed in **Other Records** to populate the third-party DNS.
  4. Note the **CloudFront Endpoint** Url shown under **Root Record**.

In the third-party domain, use the Cloudfront Endpoint as a CNAME record for "@"(apex), "www" or any other sub-domains that will point to the Webscale STRATUS environment (e.g. "store"). Use [CNAME flattening or an ALIAS](https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root) if the DNS host supports it. Otherwise an A record is required (but not preferred).

Once the DNS changes propagate, *return* to the **DNS** panel and ensure the proper domains are set per [Url guidelines.](/docs/reference/stratus/control-panels/domains/urls/)

## Using an A record

If an A record must be used,

  1. *Go to* the **DNS** panel in the Webscale STRATUS Control panel sidebar menu.
  2. *Select* the domain in the left column. The full DNS zone will appear in the right column.
  3. *Copy*  the **CloudFront Endpoint** shown.
  4. *Use* the **dig** command to discover the IP number for the CloudFront endpoints.

```
bash
dig d1xq81t8a33nfn.cloudfront.net
; <<>> DiG 9.10.3-P4-Debian <<>> d1xq81t8a33nfn.cloudfront.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16848
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;d1xq81t8a33nfn.cloudfront.net. IN      A

;; ANSWER SECTION:
d1xq81t8a33nfn.cloudfront.net. 30 IN    A       54.230.195.26
d1xq81t8a33nfn.cloudfront.net. 30 IN    A       54.230.195.46
d1xq81t8a33nfn.cloudfront.net. 30 IN    A       54.230.195.80
d1xq81t8a33nfn.cloudfront.net. 30 IN    A       54.230.195.220
```

  5. Pick any of the IPs available. They will vary depending on your geographic location.
  6. In the third-pary DNS, set any A records to any of the discovered IP numbers as needed.

> Note that CloudFront Endpoint IPs can often change and will require these steps are repeated.

## SSL Certificate Generation

DNS settings are important because they tie into the automatic SSL certificate generation service included with STRATUS.

## Clearing Local DNS Cache

If the proper DNS results are not being observed after a reasonable propagation period, clear the local DNS cached:

## Clearing DNS Cache in Windows 10

 1. *Enter* "cmd" in the Cortona search text box.
 2. *Right-click* **Command Prompt** and *select* **Run as Administrator**.
 3. *Run* the following command:
 ```ipconfig /flushdns```
 If the command succeeds, the system returns the following message:
 ```Successfully flushed the DNS Resolver Cache.```

## Clearing DNS Cache in Windows 7

 1. *Click* the **Start** button.
 2. *Enter* "cmd" in the **Start** menu search text box.
 3. *Right-click* **Command Prompt** and *select* **Run as Administrator**.
 4. *Run* the following command:
 ```ipconfig /flushdns```
 If the command succeeds, the system returns the following message:
 ```Windows IP configuration successfully flushed the DNS Resolver Cache.```

## Clearing DNS Cache in MacOS 10.10.4+

 1. *Go to* **Applications > Utilities** in the Finder.
 2. *Open* the **Terminal** application.
 3. *Run* the following command:
 ```sudo killall -HUP mDNSResponder``` and enter the Administrator password when prompted. If the command succeeds, the system does __not__ return any output.

## Flush public DNS Cache

DNS can take up to 24 hours to fully propagate. A [DNS Propagation checker](https://www.whatsmydns.net/) may be used to view the propagation progress.

If propagation time is slower than expected, Nameserver caches may be flushed using any of the following:

 1. [Google Public DNS](https://developers.google.com/speed/public-dns/cache)
 2. [OpenDNS](https://cachecheck.opendns.com/)
 3. [Cloudflare](https://cloudflare-dns.com/purge-cache/?_ga=2.63300015.1206059782.1555350629-072ababb84201bf048fe450ccb175f06)
---
# Stratus Guides - Sucuri DNS Setup
URL: https://docs.webscale.com/docs/reference/stratus/guides/dns-and-ssl/sucuri-dns-setup/
Description: Upon signing into Sucuri for the first time, *click* **Protect My Site Now** to enter your domain.



![Screenshot](/images/stratus/img/articles/sucuri1.jpg)

While entering a domain, there will be no need to select the other options provided. *Click* **Add Site** to add the domain to Sucuri.

![Screenshot](/images/stratus/img/articles/sucuri2.jpg)

Sucuri will automatically grab the IP address for a specific CloudFront edge server. While workable, it does introduce a single point of failure. To avoid this, provide Sucuri with the CNAME for the CloudFront Endpoint. This can be retrieved from the **DNS** panel of STRATUS.

![Screenshot](/images/stratus/img/articles/sucuri3.png)

1. *Modify* the **Hosting IP Address** section of Sucuri. *Add* the CNAME record from the STRATUS panel and removing the single IP address that Sucuri detected.

	![Screenshot](/images/stratus/img/articles/sucuri4.jpg)

2. *Get* the IP address of Sucuri which is provided in their overview section.

	![Screenshot](/images/stratus/img/articles/sucuri5.jpg)

3. In the **DNS** panel, *change* the entry point to CloudFront to the custom IP that was provided by Sucuri.

	![Screenshot](/images/stratus/img/articles/sucuri6.png)

With this complete, the integration is basically finished! If the Sucuri Overview screen shows *Service is Not Activated*, *wait* a few minutes then *click* the **Refresh Icon** button to update the Overview.

![Screenshot](/images/stratus/img/articles/sucuri7.jpg)

The last setting to change is in Sucuri under the **Security** section. **Enable** the option *Force passing the hostname via TLS/SSL*.

![Screenshot](/images/stratus/img/articles/sucuri8.jpg)

When using Sucuri's option that adds a *JS protector* in front of the site, [*whitelist* this path for Google Analytics validation](/docs/reference/stratus/guides/security/using-external-services/#whitelisting-validation-for-sucuri/) to work properly.
---
# Stratus Guides - Cloudflare DNS Setup
URL: https://docs.webscale.com/docs/reference/stratus/guides/dns-and-ssl/cloudflare-and-stratus/
Description: Instructions on how to configure the CloudFlare DNS to use with Webscale STRATUS.



> **NOTE:** when using Cloudflare for DNS, Webscale cannot assign or install a *Let's Encrypt* certificate; LE certficates can only be installed when using the Webscale Route 53 nameservers. Furthermore, certificates issued and signed by Cloudflare cannot be installed on Webscale STRATUS. Certificates must be issued by a publicly trusted Certificate Authority (CA), such as [ACM](https://aws.amazon.com/certificate-manager/private-certificate-authority/ "AWS Certificate Manager") or those listed by the [Mozilla Foundation](https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport "Other CA issuers"). For more information, see ["Continually Enhancing Domain Security on Amazon CloudFront"][3].

The initial setup wizard for Cloudflare will prompt to point A records instead of a CNAME. This is not an ideal setup because IPs can change and will be different depending on geographical location. Cloudflare can be allowed to pull records automatically since it will also pull the needed records for Amazon SES. Cloudflare will automatically apply CNAME flattening.

Remove the A records and change the DNS to point to the cloudfront URL for your domain. You can find this under the **DNS** Admin panel in stratus.

![Screenshot](/images/stratus/img/articles/cfstratuspanel.png)

## Sample Cloudflare DNS Setup

![Screenshot](/images/stratus/img/articles/cfdns.png)

Changing nameservers should not cause any downtime if the domain is currently pointed to stratus. However, as a precaution, proceed during off-peak hours. If the domain is not currently pointed to stratus, DNS changes can take up to 24hrs to propagate.

## Cloudflare Settings

Under **SSL > Overview**, make sure the setting is set to *FULL*.

![Screenshot](/images/stratus/img/articles/cffull.png)

Under **SSL > Edge Certificates**, make sure **Always Use HTTPS** is set to *On*.

![Screenshot](/images/stratus/img/articles/cfhttps.png)

## Cloudflare Proxy

Once the environment is behind Cloudflare, the proxy portion can be turned off any time under the DNS tab in the Cloudflare account by turning the orange cloud to a grey cloud (by clicking it).

**Proxied** example:

![Screenshot](/images/stratus/img/articles/cfproxy.png)

**Not Proxied** example:

![Screenshot](/images/stratus/img/articles/cfproxyno.png)

## Nginx Includes

By default RealIP snippets are in Sratus NGINX conf for Cloudflare IPs. This will ensure that your logs will show the real customer's IP and not a Cloudflare Proxy IP.
[Cloudflare Article](https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs-Logging-visitor-IP-addresses "Restoring original vistor IPs")

## Whitelisting Validation

It is important that an additional step be taken to whitelist the STRATUS environment in Cloudflare. Otherwise, Google Analytics validation will fail and **could result in the suspension of the account.**

See [Whitelisting Validation for Cloudflare](/docs/reference/stratus/guides/security/using-external-services/#whitelisting-validation-for-cloudflare "Instructions for whitelisting STRATUS in Cloudflare"/) for instructions.
---
# Stratus - Database Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/database/
Description: Mysql Queries

---
# Stratus Guides - MySQL Queries Gone Wild
URL: https://docs.webscale.com/docs/reference/stratus/guides/database/mysql-queries-gone-wild/
Description: For various reasons, Magento can sometime spurn queries for MySQL that can cause severe slowdown or stoppage for your Magento store. Webscale has solutions and best practices gathered from thousands of deployments over the years.


## Accessing MySQL on Webscale STRATUS

To access your Magento MySQL instance on Webscale STRATUS:

  1. Access your Magento install via SSH.
  2. Navigate to the Magento web root (typically, `public-html/`).
  3. Run `n98-magerun db:console` (Magento 1) or `n98-magerun2 db:console` (Magento 2).
  4. Run the query you desire.

## To Get Table Sizes

	SELECT CONCAT(table_schema, '.', table_name),
	      CONCAT(ROUND(table_rows / 1000000, 2), 'M') rows,
	      CONCAT(ROUND(data_length / ( 1024 * 1024 * 1024 ), 2), 'G') DATA,
	      CONCAT(ROUND(index_length / ( 1024 * 1024 * 1024 ), 2), 'G') idx,
	      CONCAT(ROUND(( data_length + index_length ) / ( 1024 * 1024 * 1024 ), 2), 'G') total_size,
	      ROUND(index_length / data_length, 2) idxfrac
	FROM   information_schema.TABLES
	ORDER  BY data_length + index_length DESC
	LIMIT  10;

## To "Blackhole" Magento 1 Log Tables

There are a number of log-related tables that get bloated very quickly. These tables are rarely referred to by Magento store owners. If you don't anticipate needing the data from these tables, then you should empty and "blackhole" them.

	delete from log_url;
	delete from log_url_info;
	delete from log_visitor;
	delete from log_visitor_info;
	delete from report_event;
	alter table log_visitor engine=BLACKHOLE;
	alter table log_visitor_info engine=BLACKHOLE;
	alter table log_url engine=BLACKHOLE;
	alter table log_url_info engine=BLACKHOLE;


## Magento 1 Viewed Products Index Table

If you are using recently viewed products on your store, then this **will not apply.** However, if you don't use recently viewed products, this is another table that, by blackholing it, it can greatly reduce the size of your MySQL database.

	DELETE from report_viewed_product_index;
	ALTER TABLE report_viewed_product_index ENGINE=blackhole;


## Magento 1 URL Rewrite Table

There are bugs in Magento 1 that cause the `core_url_rewrite` table to over-inflate with duplicate entries. It is recommended that this table should be periodically cleaned out.

	TRUNCATE TABLE core_url_rewrite;

## Magento 1 Dataflow Batch Tables

This table store pre-written results for DataFlow export and import. There is a bug in some versions of Magento where these tables are not truncated appropriately before and after an import /export. **These tables can be truncated, however they should not be blackholed.**

	TRUNCATE TABLE dataflow_batch_export;
	TRUNCATE TABLE dataflow_batch_import;

## Magento 1 Sales Flat Quote Table

This table contains a record for every shopping cart created in a Magento store, whether the cart was abandoned or converted to a purchase. Each row represents one cart.

Due to the potential size of this table, may Magento stores delete records from this table based on a certain criteria (e.g., all non-converted carts after 60 days).

To delete all carts older than 60 days:

	DELETE FROM sales_flat_quote WHERE updated_at < DATE_SUB(Now(),INTERVAL 60 DAY) AN is_active=1;


## Magento 2 Customer Visitor Table

This table has been known to get quite large and slow down a Magento store. You can delete all customer data older than 3 days, for example, with:

	DELETE FROM customer_visitor WHERE last_visit_at < DATE_SUB(NOW(), INTERVAL 3 DAY);
---
# Stratus - Cache & Session Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/caches-and-sessions/
Description: Redis Cache | Redis Sessions | Clearing Opcache

---
# Stratus Guides - Redis Cache Configuration
URL: https://docs.webscale.com/docs/reference/stratus/guides/caches-and-sessions/cache-configuration/
Description: All Webscale STRATUS Magento stores are [required to have cache enabled](/docs/reference/stratus/about-webscale-stratus/magento-requirements/) in Production environments and to use Redis for storage cache and Varnish cache for Magento 2 Full Page Cache.





> Webscale STRATUS does not allow cache to be stored in files or the database.

Redis caches are controlled and configured in the **[Redis](/docs/reference/stratus/control-panels/redis-panel/full-page-cache/)** section of the Webscale STRATUS Control panel.

## Accessing Redis Cache via SSH

The Webscale STRATUS Redis services are accessible directly via [SSH](/docs/reference/stratus/control-panels/ssh-panel/info/):

``` bash
redis-cli -h redis -p 6379
redis-cli -h redis-config-cache -p 6381
redis-cli -h redis-session -p 6380
```

In addition to the Webscale STRATUS Control panel, [Redis commands](https://redis.io/commands) can be used to control the Redis cache on the STRATUS install. With exception to Varnish for the Magento 2 FPC, Redis is recommended for all caches on Webscale STRATUS.

## Configuring Redis Caches

> [Redis Full Page Cache](/docs/reference/stratus/control-panels/redis-panel/full-page-cache/) and [Redis Sessions](/docs/reference/stratus/control-panels/redis-panel/sessions/) must be enabled in the Webscale STRATUS Control panel.

### Magento 2

Use the following commands via CLI:

  * Redis Cache

	`php bin/magento setup:config:set --cache-backend=redis --cache-backend-redis-server=redis-config-cache --cache-backend-redis-db=0 --cache-backend-redis-port=6381`

  * Redis FPC

	`php bin/magento setup:config:set --page-cache=redis --page-cache-redis-server=redis --page-cache-redis-db=0 --page-cache-redis-port=6379`

  * Redis Session

	`php bin/magento setup:config:set --session-save=redis --session-save-redis-host=redis-session --session-save-redis-log-level=3 --session-save-redis-db=0 --session-save-redis-port=6380 --session-save-redis-disable-locking=1`

### Magento 1

Add the following to the Magento *local.xml* configuration, then flush the cache to apply the change.

> Check the developer document for any 3rd party FPC module. Most support Redis. The Redis Config Cache container can be enabled in **Redis > Config Cache** in the Webscale STRATUS Control panel.

```
<cache>
  <backend_options>
    <server><![CDATA[redis]]></server>
    <port><![CDATA[6379]]></port>
    <persistent><![CDATA[]]></persistent>
    <database><![CDATA[0]]></database>
    <password><![CDATA[]]></password>
    <connect_retries><![CDATA[1]]></connect_retries>
    <read_timeout><![CDATA[10]]></read_timeout>
    <automatic_cleaning_factor><![CDATA[0]]></automatic_cleaning_factor>
    <compress_data><![CDATA[1]]></compress_data>
    <compress_tags><![CDATA[1]]></compress_tags>
    <compress_threshold><![CDATA[20480]]></compress_threshold>
    <compression_lib><![CDATA[gzip]]></compression_lib>
    <use_lua><![CDATA[0]]></use_lua>
<auto_expire_lifetime>604800</auto_expire_lifetime>
  </backend_options>
  <backend><![CDATA[Cm_Cache_Backend_Redis]]></backend>
</cache>
```

**Add for Full Page Cache** (Magento 1.x Enterprise Edition *only*)

```
<full_page_cache>
<backend>Cm_Cache_Backend_Redis</backend>
    <backend_options>
    <server>redis-config-cache</server> <!-- or absolute path to unix socket -->
    <port>6381</port>
    <persistent></persistent> <!-- Specify unique string to enable persistent connections. E.g.: sess-db0; bugs with phpredis and php-fpm are known: https://github.com/nicolasff/phpredis/issues/70 -->
    <database>0</database> <!-- Redis database number; protection against accidental data loss is improved by not sharing databases -->
    <password></password> <!-- Specify if your Redis server requires authentication -->
    <force_standalone>0</force_standalone>  <!-- 0 for phpredis, 1 for standalone PHP -->
    <connect_retries>1</connect_retries>    <!-- Reduces errors due to random connection failures -->
    <lifetimelimit>57600</lifetimelimit>    <!-- 16 hours of lifetime for cache record -->
    <compress_data>0</compress_data>        <!-- DISABLE compression for EE FPC since it already uses compression -->
    <auto_expire_lifetime>604800</auto_expire_lifetime> <!-- Force an expiry (Enterprise_PageCache will not set one) -->
    <auto_expire_refresh_on_load></auto_expire_refresh_on_load> <!-- Refresh keys when loaded (Keeps cache primed frequently requested resources) -->
    </backend_options>
</full_page_cache>
```

## Enabling Caches

The caches can be enabled using commands via SSH:

  * Magento 1 — `n98-magerun cache:enable`
  * Magento 2 — `n98-magerun2 cache:enable`

## Flushing Caches

Redis caches may need to be cleared during development or to troubleshoot a site issue. Redis cache can be flushed via SSH:

	bash
	redis-cli -h redis -p 6379 FLUSHALL
	redis-cli -h redis-config-cache -p 6381 FLUSHALL
	redis-cli -h redis-session -p 6380 FLUSHALL

> **Note:** Redis cache sessions will NOT be cleared by the command `/user/share/stratus/cli-cache.all.clear` nor will they clear during a redeployment.
---
# Stratus Guides - Session Cache Configuration
URL: https://docs.webscale.com/docs/reference/stratus/guides/caches-and-sessions/stratus-sessions-for-magento-1-and-2/
Description: Since all Magento stores on STRATUS **are required to use cache for session storage**, STRATUS provides the means of using either Redis or Memcache for caching sessions.


> **NOTE:** All Magento stores on STRATUS are required to use either Redis (recommended) or Memcache for session storage. Sessions cannot be stored in files nor in the database. See [Magento Requirements](/docs/reference/stratus/about-webscale-stratus/magento-requirements/ "STRATUS Magento Requirements"/) for the full list of requirements.

## Redis

Redis can be enabled, disabled, or flushed in the **[Redis > Config Cache][2]** STRATUS Control panel.

Using CLI commands:

  * To view: ```redis-cli -h redis-session info | tail -4```
  * To flush sessions: ```redis-cli -h redis-session -p 6380 FLUSHALL```

> NOTE: Sessions do NOT clear with the `/usr/share/stratus/cli cache.all.clear command` nor do they clear during a redeploy.

### Magento 1

To configure Magento 1 for using Redis:

  1. *Enable* the **Cm_RedisSession** module.
  	* *Open* `app/etc/modules/Cm_RedisSession.xml`.
	* *Change* "false" to "true".
	* If this file does not exist, it must be installed for the Redis module to work properly.
  2. *Edit* the "session" block in `local.xml`:

```xml
<session_save>db</session_save>
<redis_session>
<host>redis-session</host>
<port>6380</port>
<password></password>
<timeout>2.5</timeout>
<persistent></persistent>
<db>0</db>
<compression_threshold>2048</compression_threshold>f
<compression_lib>gzip</compression_lib>
<log_level>1</log_level>
<max_concurrency>20</max_concurrency>
<break_after_frontend>5</break_after_frontend>
<fail_after>10</fail_after>
<break_after_adminhtml>30</break_after_adminhtml>
<first_lifetime>600</first_lifetime>
<bot_first_lifetime>60</bot_first_lifetime>
<bot_lifetime>7200</bot_lifetime>
<disable_locking>1</disable_locking>
<min_lifetime>60</min_lifetime>
<max_lifetime>2592000</max_lifetime>
</redis_session>
```

### Magento 2

There are two methods to configure Magento 2 for Redis:

  * Via SSH, *run* `php bin/magento setup:config:set --session-save=redis --session-save-redis-host=redis-session --session-save-redis-log-level=3 --session-save-redis-db=0 --session-save-redis-port=6380`

	or

  * *Edit* the "session" block in `env.php`:

```php
php
'session' =>
array (
  'save' => 'redis',
  'redis' =>
  array (
    'host' => 'redis-session',
    'port' => '6380',
    'password' => '',
    'timeout' => '2.5',
    'persistent_identifier' => '',
    'database' => '0',
    'compression_threshold' => '2048',
    'compression_library' => 'gzip',
    'log_level' => '1',
    'max_concurrency' => '20',
    'break_after_frontend' => '5',
    'break_after_adminhtml' => '30',
    'first_lifetime' => '600',
    'bot_first_lifetime' => '60',
    'bot_lifetime' => '7200',
    'disable_locking' => '1',
    'min_lifetime' => '60',
    'max_lifetime' => '2592000'
  )
),
```

## Memcache

As an alternative to Redis for session cache, Memcache may be used. Memcache status can be observed and the sessions flushed using the **[Memcache](/docs/reference/stratus/control-panels/info/ "Memcache Panel"/)** STRATUS Control panel.

### Magento 1

*Edit* your session block in `local.xml` to enable Memcache sessions on your Magento 1 store if using PHP 5.6:

``` xml
<session_save><![CDATA[memcache]]></session_save>
<session_save_path><![CDATA[tcp://memcache:11211?persistent=0&weight=2&timeout=60&retry_interval=10]]></session_save_path>
```

If you are using PHP 7.0 or higher with Magento 1, use the following instead:

``` xml
<session_save><![CDATA[memcached]]></session_save>
<session_save_path><![CDATA[memcache:11211?persistent=0&weight=2&timeout=60&retry_interval=10]]></session_save_path>
```

### Magento2

*Edit* your "session" block in `env.php` to enable Memcache sessions on your Magento 2 store.

``` php
'session' =>
   array (
      'save' => 'memcache',
      'save_path' => 'tcp://memcache:11211'
),
```

For Magento version 2.3+, *add* the following under `PHP > OPTIONS`:

``` php
session.save_handler=memcache
session.save_path=memcache:11211
```
&nbsp;
---
# Stratus Guides - Clearing Opcache
URL: https://docs.webscale.com/docs/reference/stratus/guides/caches-and-sessions/opcache/
Description: If your code deploys use symlinks or you think something is cached in the PHP opcache, you can clear it via the php-fpm port. The Webscale STRATUS CLI can also be used to clear the opcache instead of this method.



> The [Webscale STRATUS CLI](/docs/reference/stratus/guides/webscale-stratus/stratus-cli/) can also be used to clear the opcache instead of this method.

On all Webscale STRATUS sites, the hostname:port is _phpfpm:9000_.

To use [Cachetool](https://gordalina.github.io/cachetool/), configure these settings in `.cachetool.yml`:

```bash
adapter: fastcgi
fastcgi: php-fpm:9000
temp_dir: /srv/tmp
```

For PHP 7.0.x, *download* the following file:

```wget -c https://github.com/gordalina/cachetool/raw/gh-pages/downloads/cachetool-3.2.1.phar```

For PHP 7.1 or 7.2, *download*:

```wget -c http://gordalina.github.io/cachetool/downloads/cachetool.phar```

The file must be renamed *.cachetool.yml*. CacheTool will look for this file in the current directory.

&nbsp;
---
# Stratus Security Guides - Blocking Countries
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/block-countries/
Description: Magento stores, like so many e-commerce stores, are regularly targets for fraud and malicious traffic. Additionally, stores should not be using resources to handle traffic from locations they do not service or ship to.


Webscale STRATUS gives you the ability to block traffic from selected countries.

To block certain countries from accessing a Webscale STRATUS install, use **[Access > Block Countries](https://docs.webscale.com/reference/stratus/control-panels/access-panel/block-countries/)** in the Webscale STRATUS Control panel.
---
# Stratus - Security Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/
Description: Blocking Countries | Magento | Traffic Limits | Magento 1 | External CDNs and Firewalls | OSCP Stapling

---
# Stratus Security Guides - Securing a Magento Store
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/securing-your-store/
Description: Magento stores on Webscale STRATUS are protected by a Web Application Firewall (WAF). Every request to a store must first pass a host of WAF rules designed to repel hackers and other attempts to compromise a store.


Regardless of these efforts, an e-commerce store remains accessible by the public-at-large and therefore can be subject to additional attempts to compromise security.

To give your store additional protections,

  * Don't use the default admin or backend login path. Using **/admin** is a common path too often used by hackers to make repeated attempts to gain access. Magento 2 automatically creates an obscure admin path. For Magento 1.x stores, the default "admin" path should be changes to a obscure value resembling a very secure password (e.g., "Uy49kkT" or "j87PenM").
  * Install all updates and patches. The [Magento Security Center](https://magento.com/security) is a Magento resource for recent and past updates. The community site, [magesec.org](https://magesec.org/), has open source scanning and patching tools.
  * Many sites hosted on Mojo STRATUS use WordPress for their blog feature. Using [Nginx Includes](/docs/reference/stratus/control-panels/nginx-panel/includes/) or the built-in [STRATUS panel access restriction](/docs/reference/stratus/control-panels/access-panel/controlling-access/), restrict the WordPress login by IP and prevent brute-force attacks.

```
location ~* /wordpress/wp-login.php$ {
  allow 1.1.1.1;
  try_files $uri $uri/ /index.php?$args;
 location ~* \.php$ { try_files /dummy @proxy; }
  deny all;
}
```

  * Remove all extraenous files from the Magento web root. Extra database dumps, un-needed files and test scripts, and other code that isnt necessary for production is often left exposed.
  * Use strong passwords!
  * [Block countries for which shipping is not available.](/docs/reference/stratus/guides/security/block-countries/)
---
# Stratus Security Guides - Traffic Limits
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/stratus-traffic-limits/
Description: Webscale STRATUS is a multi-tenant architecture using micro-services to provide the ideal hosting environment for Magento.

 Certain services are restricted in terms of how much CPU and memory they can use to prevent memory leaks and other issues from affecting your site.  Services that need fluid limits, like PHP, are handled differently.

The Redis, memcache, Nginx and Elasticsearch services all have lower memory limits with less than 4GB as a maximum. A majority of stores do not exceed them and our team can adjust them if needed.

**Varnish malloc** is set to 1GB, and Varnish generally only has 1 GB of memory associated with it, assuming it can use it all. Static caching is disabled by default in the Magento 2 VCL: only FPC information is stored in Varnish while CloudFront is used for static asset caching.

**PHP-FPM** scales horizontally and is restricted to 50% of the CPU available on a physical node, and when autoscaling is enabled, it expands horizontally based on the CPU utilization.

# Rate limits

We have several rate limits and other blocks in place on Webscale STRATUS to prevent malicious attacks against customers' stores.

> For security purposes, the exact limits are not available publicly.

## Limited URLs

URLs containing, but not limited to, these phrases are rate limited:

  * catalogsearch

## User Agents

User agents containing, but not limited to, these strings are blocked. These blocks are controlled in the **[Access > Block Bots][1]** panel of your Webscale STRATUS Admin panel.

  * yandex
  * baidu
  * megaindex
  * ru_bot
  * dotbot
  * ahrefs
  * mj12

## Countries

You may select what countries to block or unblock in the **[Access > Block Countries][2]** section of your Webscale STRATUS Admin panel.

## Plan API Rate Limits

Our plans have specific limits for the API endpoints on Magento 1 and 2.

* **Starter** — 2 requests/second

* **Pro** — 25 requests/second

* **Pro-Plus** — 25 requests/second

* **Pro-Elite** — 30 requests/second

* **Growth** — 35 requests/second

* **Scale** — 50 requests/second

* **Enterprise** &#8211;— 75 requests/second

* **Custom** — 100+ requests/second
---
# SStratus Security Guides - Securing Magento 1.x against malware and brute force attacks
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/securing-magento-1-x-against-malware-and-brute-force-attacks/
Description: Brute force attacks against Magento stores are unfortunately common, as with any popular web framework. Fortunately, they are easily countered as they are often lazy attacks from automated scripts or botnets that try to use the default Magento paths to gain entry.


Our support team at Webscale can help implement any of the changes below to help protect your store.

To help protect your store against attacks, do the following:

  * **Change the admin path** from */admin* to something less obvious. This is adjusted in the `local.xml` file near the bottom. Change the **frontName** variable and clear the Magento cache.
  * **Password or IP restrict the downloader** using the Webscale STRATUS **[Access > Protect URL][2]** panel access restrictions or a `.htaccess` file. The downloader can also be moved out of the Magento web root completely when not actively using Magento Connect.
  * **Update Magmi**, as older versions of Magmi are unsecure and can allow remote users to upload files for remote execution.
  * **Keep any WordPress installations up to date** within the Magento web root. WordPress plugins can often be found to introduce or allow malware.
  * **Apply any missing patches for your store**. Our support can help apply these for you. Most Magento 1.x patches are **critical **to security

## Further securing your Magento admin

If changing the admin path is not sufficient, it is also possible to IP restrict it entirely. Contact stratus-support@webscalenetworks.com for details on how to restrict this.
---
# Stratus Security Guides - External CDNs and Firewalls
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/using-external-services/
Description: Some customers may want to use CloudFlare or Sucuri because they already have various pre-configured security and DNS settings. **Some of their security features can interfere with our site validation which in turn can impact billing.**


## Whitelisting Validation for Sucuri

When using Sucuri's firewall that adds a JS protector in front of the site, whitelist a specific path for our validation to work properly. Whitelisting this path will not compromise the protection on the rest of your site. Our validator uses a simple curl request and cannot process Sucuri's JS.

1. *Note* the UUID of your Webscale STRATUS instance.
	 * *Go to* **Info** panel in the Webscale STRATUS Admin panel.
	 * **Account Name** is the *UUID* of the install.
2. *Log into* the Sucuri.net account
3. *Select* the one domain to adjust.
4. *Click* the **Firewall** option from the top navigation menu.
5. *Click* **Access Control**.
6. *Click* **Whitelist URL Paths** from the left-hand navigation menu.
7. *Whitelist* the hidden path as shown, substituting the noted *UUID* where shown:

		https://magemojo.com/stratus/#/stratus/[UUID]/info

	{{< figure src="/images/stratus/img/articles/whitelist_uuid.png" >}}

8. *Click* **Whitelist** to apply the change.
9. *Confirm* the change with a curl command such as

		curl https://yourwebsite.com/.[UUID]

	The result returned should be *200* with "validated."

## Whitelisting Validation for Cloudflare

1. *Note* the UUID of your Webscale STRATUS instance.
	 * *Go to* **Info** panel in the Webscale STRATUS Admin panel.
	 * **Account Name** is the *UUID* of the install.
2. *Log in* to your Cloudflare.com account.
3. *Click* the **Firewall Icon** in the top menu.
4. *Click* the menu **Firewall Rules** that appears underneath.

	{{< figure src="/images/stratus/img/articles/whitecf1.jpg" >}}

5. *Click* **Create Firewall Rule**.
6. *Whitelist* the hidden path as shown, substituting the noted *UUID* where shown:

		https://magemojo.com/stratus/#/stratus/[UUID]/info

	{{< figure src="/images/stratus/img/articles/whitecf2.jpg" >}}
7. *Click* **Deploy** to save the change.
8. *Confirm* the change with a curl command such as

		curl https://yourwebsite.com/.<uuid>
---
# Stratus Security Guides - OSCP Stapling
URL: https://docs.webscale.com/docs/reference/stratus/guides/security/oscp-stapling/
Description: All traffic on Mojo STRATUS goes through CloudFront which already has Online Certificate Status Protocol (OSCP) stapling enabled. Because of how this is implemented in CloudFront, OSCP may not show when tested.


According to Amazon Web Services:

>When a viewer submits an HTTPS request for an object, either CloudFront or the viewer must confirm with the certificate authority (CA) that the SSL certificate for the domain has not been revoked. OCSP stapling speeds up certificate validation by allowing CloudFront to validate the certificate and to cache the response from the CA, so the client doesn't need to validate the certificate directly with the CA.

>The performance improvement of OCSP stapling is more pronounced when CloudFront receives numerous HTTPS requests for objects in the same domain. Each server in a CloudFront edge location must submit a separate validation request. When CloudFront receives a lot of HTTPS requests for the same domain, every server in the edge location soon has a response from the CA that it can "staple" to a packet in the SSL handshake; when the viewer is satisfied that the certificate is valid, CloudFront can serve the requested object. If your distribution doesn't get much traffic in a CloudFront edge location, new requests are more likely to be directed to a server that hasn't validated the certificate with the CA yet. In that case, the viewer separately performs the validation step and the CloudFront server serves the object. That CloudFront server also submits a validation request to the CA, so the next time it receives a request that includes the same domain name, it has a validation response from the CA.

**Source**: [AWS Developer Guide](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-ocsp-stapling)
---
# Stratus Magento 1 Guides - Cache Management
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/cache-management/
Description: The cache in Magento 1.X is managed under **System->Cache Management.**


{{< figure src="/images/stratus/img/articles/cache_management.png" alt="magento-19" >}}

After clicking that link, you should see a full list of your caches, similar to below. The types of caches may vary depending on what extensions/FPCs or even Varnish modules you have enabled.

{{< figure src="/images/stratus/img/articles/cache-management-2.png" alt="magento-83" >}}

In the above case, we see this site is using the standard Magento caches alongside Varnish through the Turpentine module. Caches that are invalidated with show up as **Invalidated** in a red bubble under the **Status** column. Invalidated is not necessarily bad, it just means the caches are out of date and could be serving older content.

## Flushing the Cache

  1. Log into your Magento admin
  2. Go to the **System->Cache Management**
  3. Check the boxes on the left for the caches you want to flush  
  {{< figure src="/images/stratus/img/articles/flushing-cache-1.png" alt="flush-81" >}}
  4.  Select **Refresh** from the actions drop-down in the top right  
  {{< figure src="/images/stratus/img/articles/flushing-cache-2.png" alt="flush-32" >}}
  5. Hit Submit; those caches are now refreshed/flushed for you

Alternatively, you can flush every cache by clicking near the **Flush Cache** button top right of the Cache Management area.

You can also run n98-magerun.phar cache:flush on Stratus or other n98 equipped servers. Or delete the contents of var/cache in your Magento install if you are using the files cache.

### Flushing Redis Cache

If your site is using Redis-cache, the above methods should still work to clear/refresh the cache. But you can also flush redis specifically on Stratus by running this command via SSH
```
$ redis-cli -h redis -p 6379 flushall
OK
```
---
# Stratus - Magento 1 Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/
Description: Caches | Index Mode | Invoicing Errors | Log Cleaning | Unknown Ciphers | Patching | Product Image Uploader Errors | Cookie Settings | Sales Report Errors

---
# Stratus Magento 1 Guides - Change Index Mode
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/change-index-mode/
Description: Understanding Magento 1.X cache management in Webscale STRATUS.


The Magento 1.x indexer has two settings **Update on Save** and **Manual** update.  There are several ways to adjust this setting, but the easiest is via the Magento Admin.

You can set it on Stratus by running this command via SSH from within the docroot of your Magento 1 install:
```
$ php shell/indexer.php --mode-manual
```

To avoid problems when multiple updates are being performed that trigger automatic reindexing, set all indexers to manual. Otherwise, every time an object is saved, a full reindex will be triggered and any affected objects with dependencies might cause a deadlock. Symptoms of a deadlock include high CPU usage and MySQL errors. As a best practice, schedule indexing as a cron job or run it manually to prevent deadlocks from occurring.
Setting indexers to manual is a requirement under our <a href="/reference/stratus/about-webscale-stratus/magento-requirements/">TOS</a>.
---
# Stratus Magento 1 Guides - Invoicing printing blank or 500 error
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/invoicing-printing-blank-or-500-error/
Description: If you moved to a server with PHP 5.4, you might get blank invoices from your admin when using the **Print Invoice** button.


If you Googled this, you probably found yet another StackOverflow link &#8211; <a class="external-link" style="line-height: 1.42857;" href="http://stackoverflow.com/questions/17022829/magento-blank-empty-page-whene-printing-invoice-on-backend" rel="nofollow">http://stackoverflow.com/questions/17022829/magento-blank-empty-page-whene-printing-invoice-on-backend</a>

**<u>From the above link:</u>**

Make a core override:

Copy &#8211; [magento root]/lib/Zend/Pdf/FileParserDataSource.php

To &#8211; [magento root]/app/code/local/Zend/Pdf/FileParserDataSource.php

<pre>Fixed it by commenting out __construct() and __destruct() methods in lib/Zend/Pdf/FileParserDataSource.php

//    abstract public function __construct();

    /**
     * Object destructor. Closes the data source.
     *
     * May also perform cleanup tasks such as deleting temporary files.
     */
//    abstract public function __destruct();
</pre>

Then clear Magento cache and test.
---
# Stratus Magento 1 Guides - Log Cleaning
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/log-cleaning/
Description: Magento 1.X stores several logs in the Magento database related to visitors of your site.

# Log Cleaning

A few of these tables are:

  * log_url
  * log\_url\_info
  * log_visitor
  * log\_visitor\_info

If these tables get very large, they can slow down your frontend and backend considerably (when you hit several hundred thousand rows).  To clean these manually, you can do so via the MYSQL command line with a query like this &#8211;

```
delete from log_url;delete from log_url_info;delete from log_visitor;delete from log_visitor_info;
```

With these cleared, you should lower the retention period via **System->Advanced->System**

{{< figure src="/images/stratus/img/articles/log-cleaning.png" alt="Log-Cleaning.png" >}}
---
# Stratus Magento 1 Guides - Magento 1.9 Unknown cipher in list
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/magento-1-9-unknown-cipher-in-list-tlsv1/
Description: If you have updated Magento to 1.9.2, you may encounter this error when using the downloader. The problem is due to older ciphers.


 This is fixed by adjusting one line of code.

To correct this, in downloader/lib/Mage/HTTP/Client/Curl.php, change:

<pre class="">$this\-\&gt;curlOption(CURLOPT_SSL_CIPHER_LIST, 'TLSv1');</pre>

to

<pre> $this-&gt;curlOption(CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);</pre>
---
# Stratus Magento 1 Guides - Patching Magento 1
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/patching-magento-how-to-guide/
Description: For Magento 1, patch using the community patching tool.


The community patching tool applies EVERYTHING for you &#8211; https://github.com/magesec/magesecuritypatcher
---
# Stratus Magento 1 Guides - Product image uploader does not work
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/product-image-uploader-does-not-work/
Description: The SWF uploaders have been blocked permanently as a security measure. They were updated and removed in the Magento patch 8788.


To fix this, you must patch your store. There are no exceptions. The malware involved has been compromising store security and leading to credit theft. Security outweighs convenience in this case, unfortunately.

You may encounter issues such as &#8211;

  *  broken forms, getting to patch 8788 requires all previous patches will cause issues with form keys on custom templates, this can break things like the customer login or registrations, which we cannot support fixing, though our patch attempts to add them to all the forms we can detect
  * the image uploader may remain broken after patching if there are core overrides, certain modules, or custom admin templates that affect it or rely on the old flash uploader. This is something else we cannot support fixing unfortunately

Roughly 10% of patched stores run into some issue that we have seen. Let us know if you need assistance applying the latest patches.
---
# Stratus Magento 1 Guides - Recommended Cookie Settings
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/recommended-cookie-settings/
Description: Recommended cookie settings for Magento 1 stores.


In Magento 1 under **System->Configuration->Web **then _Session Cookie Management_ you will see a form like this:

![cookies](/images/stratus/img/articles/cookie-settings.png)

In general, we recommend the following settings &#8211;

  * Lifetime at least 86400 (1 day)
  * Path /
  * Cookie domain exactly matches your domain or is .example.com if you are using www in your domain name
  * HTTP Only **Yes**
  * Cookie Restriction Mode **No**

## Cookie domain issues

The cookie domain can cause problems such as

  * Failed customer logins
  * Broken carts (products won&#8217;t add)
  * Cart empties on page load
  * Cart empties at checkout
  * Cannot log into the Magento backend/admin

Because of this, you may need to try various cookie domain settings depending on your exact site URL. For example, a sub-domain typically requires the cookie domain to match the sub-domain i.e. mysite.example.com exactly

## Cookie Restriction Mode

If this is set to yes, users visiting with cookies disabled will be redirected to the /enable-cookies page your Magento install. 
---
# Stratus Magento 1 Guides - Sales Reports are blank
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-1/sales-reports-are-blank/
Description: In sections like Reports → Sales → Orders, any given report may have blank data using any or some time periods.


 This section requires generating the lifetime stats.  Do this via Reports → Refresh Statistics.

Then **Select All** and in the **Actions** drop-down refresh lifetime stats.  This may take a while and once complete your reports should work.
---
# Stratus - Magento 2 Guides
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/
Description: Improving Cron | Elasticsearch Configuration | Composer | Customer Grid Empty | Deploying Static Files | Email Sender Incorrect | Site Changes Not Appearing | Purging Varnish | SMTP | Magento 2 modes | Cron Explained | Upgrade Recommendations | Baler | Terser | Consumer Brokers | Extensions | Sitemaps | Media Gallery

---
# Stratus Magento 2 Guides - Improving the Cron
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/magemojo-cron/
Description: The cron functionality in Magento 2 is problematic and doesn't consistently work at a dependable level. To satisfy this issue, MageMojo created and supports its own Magento 2 Cron extension.



> **NOTE:** All Magento 2 stores hosted on STRATUS are required to install the MageMojo Cron extension.

MageMojo's (now Webscale Stratus) engineers have completely rewritten the Magento 2 cron functionality to fix the inherent bugs and to be much more resistant to failure.

**The MageMojo Cron extension is free to install** and may be installed by the store owner or developer, *or* Webscale Stratus support will install the extension at **no additional cost**.

To request an installation, please open a support ticket in your Stratus account dashboard.

To download the extension for self-installation, visit the [M2 Cron extension GitHub](https://github.com/magemojo/m2-ce-cron).
---
# Stratus Magento 2 Guides - Configure Elasticsearch
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/elasticsearch-and-elasticsuite/
Description: After [choosing the version](/docs/reference/stratus/control-panels/elasticsearch-panel/version/) & enabling [Elasticsearch in Webscale STRATUS](/docs/reference/stratus/control-panels/elasticsearch-panel/info/), it must be configured in the Magento 2 Admin.



  1. *Log into* the Magento 2 Administration backend.
  2. *Go to* **Stores > Configuration**.
  3. *Go to* **Catalog > Catalog** in the sidebar menu.
  {{< figure src="/images/stratus/img/articles/configure-elasticsearch-1.png" >}}
    * De-select* **Search Engine : Use system value**.
    * **Elasticsearch Server Hostname** — *Enter* "elasticsearch".
  4. *Click* **Test Connection** to validate the settings.
  5. *Click* **Save Config** to save the changes.

 After activating Elasticsearch, re-index the *catalogsearch_fulltext* index using the Magento Admin, SSH access, or the Webscale STRATUS Control panel [CLI commands](/docs/reference/stratus/control-panels/application-panel/cli-commands/).
---
# Stratus Magento 2 Guides - Composer
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/composer-and-magento-2/
Description: Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and will manage (install/update) them for you.


Instead of identifying, installing, and configuring a PHP library independently, libraries can be specified in a JSON setup file.

Magento 2 relies on composer (though you can avoid it) through several repositories.

Composer for Magento 2 is pre-installed on MageMojo servers. To install, *run*:

	composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

## How Composer Works

When Composer is called by this command, it first creates a project and pull in an existing package — in this case, Magento 2. The project will be created, for this example, in the `magento/project-community-edition` directory.

Composer retrieves the package from a git repository, as a clone, and runs the `composer.json` file to retrieve everything else that may be required for the project.

## Composer.json

After the initlal pull, Composer uses the `composer.json` to get all the packages.

The following is the `composer.json` file for Magento 2.1.1.

	{
	    "name": "magento/project-community-edition",
	    "description": "eCommerce Platform for Growth (Community Edition)",
	    "type": "project",
	    "version": "2.1.1",
	    "license": [
	        "OSL-3.0",
	        "AFL-3.0"
	    ],
	    "require": {
	        "magento/product-community-edition": "2.1.1",
	        "composer/composer": "@alpha"
	    },
	    "require-dev": {
	        "phpunit/phpunit": "4.1.0",
	        "squizlabs/php_codesniffer": "1.5.3",
	        "phpmd/phpmd": "@stable",
	        "pdepend/pdepend": "2.2.2",
	        "fabpot/php-cs-fixer": "~1.2",
	        "lusitanian/oauth": "~0.3 &lt;=0.7.0",
	        "sebastian/phpcpd": "2.0.0"
	    },
	    "config": {
	        "use-include-path": true
	    },
	    "autoload": {
	        "psr-4": {
	            "Magento\\Framework\\": "lib/internal/Magento/Framework/",
	            "Magento\\Setup\\": "setup/src/Magento/Setup/",
	            "Magento\\": "app/code/Magento/"
	        },
	        "psr-0": {
	            "": "app/code/"
	        },
	        "files": [
	            "app/etc/NonComposerComponentRegistration.php"
	        ]
	    },
	    "autoload-dev": {
	        "psr-4": {
	            "Magento\\Sniffs\\": "dev/tests/static/framework/Magento/Sniffs/",
	            "Magento\\Tools\\": "dev/tools/Magento/Tools/",
	            "Magento\\Tools\\Sanity\\": "dev/build/publication/sanity/Magento/Tools/Sanity/",
	            "Magento\\TestFramework\\Inspection\\": "dev/tests/static/framework/Magento/TestFramework/Inspection/",
	            "Magento\\TestFramework\\Utility\\": "dev/tests/static/framework/Magento/TestFramework/Utility/"
	        }
	    },
	    "minimum-stability": "alpha",
	    "prefer-stable": true,
	    "repositories": [
	        {
	            "type": "composer",
	            "url": "https://repo.magento.com/"
	        }
	    ],
	    "extra": {
	        "magento-force": "override"
	    }
	}

Parts of this file are obvious according to the name/description pairs within.

The `require` section is where the magic begins. This section specifies the packages to be added to the project from the repositories listed.  `require-dev` is also installed but can be excluded in the initial install with the proper flag (no-dev).

The packages for phpunit and other testing tools are in the `vendor` directory in Magento 2. The `psr-4` and `psr-0` terms are different autoloading specifications in PHP.

`config` will check for other items within the path to [add to the autoloader](https://getcomposer.org/doc/06-config).

**Autoloading** is another useful feature of Composer. Based on the `autoload` section, Composer will generate a file named `autoload.php` in the `vendor` directory. This ties into the bootstrap process `index.php` under Magento 2 and automatically includes needed code throughout the store so it can work without having to manually add requirements and other configurations throughout the code.

`minimum-stability` and `prefer-stable` would only change to specifically use a development or other branch of Magento 2. For the stable releases, this will not change and it is used for production circumstances. A developer interested in contributing to Magento 2 would use this.

`repositories` are the code sources and was also part of the initial pull when the Magento 2 install began.

> You do not have to use Composer, but it is highly recommended. Modules and themes can integrated into composer to package them together for easy deployment. The alternative is manually (or scripting out) bespoke or custom deployments or relying on git to manage sub-packages in Magento 2. With composer, a Magento 2 site can be quickly created anywhere (minus the specific store data) within minutes.
---
# Stratus Magento 2 Guides - Customer Grid Empty
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/customer-grid-empty/
Description: The customer list in Magento 2 may appear empty despite the fact there are many rows/customers in  the customer_entity table.


The customer list in Magento 2 may appear empty despite the fact there are many rows/customers in  the `customer_entity` table. The grid depends on an indexer called the *customer\_grid* index that stores data in the `customer_grid_flat` table. In this case, the flat table has not been properly populated by the indexer.

By tracing the indexer, it may show a "hang" on a query such as the following:

	sendto(5, ",\7\0\0\3SELECT `e`.*, `e`.`entity_id`, TRIM(CONCAT_WS(' ', IF(`e`.`prefix` <> '', `e`.`prefix`, NULL), IF(`e`.`firstname` <> '', `e`.`firstname`, NULL), IF(`e`.`middlename` <> '', `e`.`middlename`,<br />
	NULL), IF(`e`.`lastname` <> '', `e`.`lastname`, NULL), IF(`e`.`suffix` <> '', `e`.`suffix`, NULL))) AS `name`, `e`.`email`, `e`.`group_id`, `e`.`created_at`, `e`.`website_id`, `e`.`confirmation`,<br />
	 `e`.`created_in`, `e`.`dob`, `e`.`gender`, `e`.`taxvat`, (SELECT `lookup`.`last_visit_at` FROM `customer_visitor` AS `lookup` WHERE (`lookup`.`customer_id` = `e`.`entity_id`) ORDER BY `lookup`.`last_visit_at`<br />
	DESC LIMIT 1) AS `last_visit_at`, TRIM(CONCAT_WS(' ', IF(`shipping`.`street` <> '', `shipping`.`street`, NULL), IF(`shipping`.`city` <> '', `shipping`.`city`, NULL), IF(`shipping`.`region` <> '',<br />
	`shipping`.`region`, NULL), IF(`shipping`.`postcode` <> '', `shipping`.`postcode`, NULL))) AS `shipping_full`, TRIM(CONCAT_WS(' ', IF(`billing`.`street` <> '', `billing`.`street`, NULL), IF(`billing`.`cit"...,<br />
	 1840, MSG_DONTWAIT, NULL, 0) = 1840


The problem, in this case, is the `customer_visitor` table. By inspection, if the table has several hundred thousands of rows, it should be emptied and reindexing again attempted.

> The status in the `indexer_state` table may need updating.

	update indexer_state set status="invalid" where state_id=1;

The customer grid should now populate.
---
# Stratus Magento 2 Guides - Deploying static files
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/deploying-static-files/
Description: For performance, Magento 2 generates static files from your theme and other site components. This feature is well documented in the [Magento 2 dev docs][1], but there are some tricks to deploying and generating these files on a Webscale server.


Before deploying static files, remove any files — *except* the .htaccess file —  in `pub/static`.

The following should also be removed, especially when doing a production deployment.

* All folders under `pub/static`
* `var/cache`
* `var/composer_home`
* `var/generation`
* `var/page_cache`
* `var/view_preprocessed`
* `var/di` (if present)

Then the static files can be deployed using the following command (run from the bin directory in the Magento install).

	php bin/magento setup:static-content:deploy
---
# Stratus Magento 2 Guides - Email Sender Incorrect
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/magento-2-email-sender-incorrect/
Description: If using Magento 2.2.4 or higher - either new or as an upgrade from 2.2.x — there is a bug that alters the email sender name. This bug changes your preset in the store configuration, **General->Store Email Address**, to the server usernames. Webscale Stratus has tested and confirmed the bug and a fix to disable all the Amazon modules.


For example,

**2.2.3** — sales@example.com

may become,

**2.2.4** — www-data@…mojostratus.io

A [github issue](https://github.com/magento/magento2/issues/14952 "Github Issue") is tracking this. MageMojo has tested and confirmed the bug and a fix is to disable all the Amazon modules:

	Amazon_Core
	Amazon_Login
	Amazon_Payment

To disable these modules, run:

	php bin/magento module:disable Amazon_Login
	php bin/magento module:disable Amazon_Payment
	php bin/magento module:disable Amazon_Core

Then redeploy production mode for the Magento 2 store.
---
# Stratus Magento 2 Guides - Site Changes Not Appearing
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/none-of-my-site-changes-appear-in-magento-2/
Description: If product or theme changes on a Magento 2 site are not showing, there are numerous caches that might need to be cleared.



## Caches
If product or theme changes on a Magento 2 site are not showing, there are numerous caches that might need to be cleared. In no particular order, check all of these sources:

  * Re-deploy static files (clear `pub/static`, then deploy)
  * Re-compile or reset production mode (this also clears static files)
  * Flush and clean the Magento 2 cache
  * Clear the local browser cache or test with an incognito tab in Chrome or private tab in Firefox
  * Use [/usr/share/stratus/cli cache.all.clear][1]

## Clearing Varnish

The easiest way to do clear Vanish without root access:

1. *Go to* **Varnish > Info** in the STRATUS Admin panel.
2. *Click* **Flush Cache**.

## Reinit Autoscaling or ZDD

If autoscaling is **on** and [ZDD (Zero Downtime Deployment)][3] is not enabled, the changes are in a folder that is included in the autoscaling configuration, the autoscaling may need reinitializing.
To reinitialize, run the [/usr/share/stratus/cli autoscaling.reinit][2] command.

If ZDD is enabled, you will need to run the commands to make your new code live. [/usr/share/stratus/cli zerodowntime.init][4] then [/usr/share/stratus/cli zerodowntime.switch][5]
---
# Stratus Magento 2 Guides - Purge the Varnish FPC
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/purge-the-varnish-fpc/
Description: The Webscale STRATUS CLI is the best way to clear Varnish via the SSH container.


	/usr/share/stratus/cli cache.varnish.clear

Curl also works if you are using SSH. The Varnish hostname is **varnish**:

	curl -X 'PURGE' -H'X-Magento-Tags-Pattern: .*' varnish

Magento 2 users should set their *http-cache-host* accordingly:

	php bin/magento setup:config:set --http-cache-hosts=varnish

Once the above is set, a typical cache clear via the Magento 2 admin or Magento commands is possible:

	php bin/magento cache:clean

Varnish can also be purged via the **Flush Cache** button in the **Varnish > Info** Webscale STRATUS Admin panel.

## Static Files Not Refreshing

Older Magento 2 versions have a bug in the VCL where static files will not refresh despite the purge listed above. See [https://github.com/magento/magento2/issues/8113](https://github.com/magento/magento2/issues/8113)

As a workaround, *run* this command via shell access on your MageMojo server:

	varnishadm "ban req.url ~ "/" "

## Further reading

For more understanding about Magento 2 and Varnish, please read the official dev docs at [https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/cache/varnish/use-varnish-cache.html](https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/cache/varnish/use-varnish-cache.html)
---
# Stratus Magento 2 Guides - Send store mail via SMTP
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/send-store-mail-via-smtp/
Description: Out of the box, both Magento 1 and 2 send email using PHP and Sendmail. This means rather than sending sales or order emails to customers via an existing mail service, such as Mandrill or an Exchange server, the email goes out directly from the Webscale STRATUS environment.


While this works fine in most cases, we do recommend using an SMTP module or plugin for either version of Magento to improve deliverability. Especially for high traffic stores.  Sending a lot of emails daily runs the risk of having the server blocked by the major email providers such as Gmail or Hotmail due to volume. Sending out through dedicated services like Mandrill or Sendgrid allows the sending of higher volumes without the risk of blacklisting.

## Magento 1 SMTP

Webscale recommends Aschroders SMTP Pro extension for Magento 1. It is free and reliable, and availabe on [Github](https://github.com/aschroder/Magento-SMTP-Pro-Email-Extension) or [Magento Connect](https://www.magentocommerce.com/magento-connect/smtp-pro-email-free-custom-smtp-email.html).

## Magento 2 SMTP

Currently, we do not have direct experience with a particular SMTP plugin for Magento 2. There are several available and even one specifically for Sendgrid. Two are listed below which are free. Unfortunately, we cannot guarantee their reliability, however.

  * <https://github.com/magepal/magento2-gmailsmtpapp>
  * <https://github.com/yukoff/magento2-sendgrid-smtp>
---
# Stratus Magento 2 Guides - Set Magento 2 modes
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/set-magento-2-modes/
Description: Magento 2 has several modes that amount to different configuration states which either enhance performance or enable various development tools.



Please read the development documentation on [Magento 2 modes](https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/setup/application-modes.html) for in-depth information.

* Default mode

	This mode is "halfway" between development and production. Static files are enabled, but compilation is not.

* Production mode

	All the caching and compilation features are enabled for performance. Updates to your site theme or other content may not appear without re-deploying this mode. Caching will be used for all requests which are why updates are ignored until this content is refreshed via the Magento 2 cache, static files, and compilation.

* Developer mode

	Performance in developer will be significantly less, but this is expected as Magento 2 will have more verbose logging and debugging enabled, which should always be on during active development. Switch to production mode for performance testing.

## Changing the mode

Much like [static files](/docs/reference/stratus/guides/magento-2/deploying-static-files/), changing the mode involves running a Magento command:

	php bin/magento deploy:mode:set production
	#for default/dev replace production with default or developer

&nbsp;
---
# Stratus Magento 2 Guides - Cron Explained
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/the-magento-2-cron/
Description: As added by default in the Stratus panel under **[Cron > Schedule](/docs/reference/stratus/control-panels/cron-panel/schedule/)**, the Magento 2 cron consists of 3 separate tasks that should be set as follows. Replace *webroot* with the full path to your install. Below are the defaults assuming the webroot is `public_html` on Webscale STRATUS.



```
/usr/local/bin/php /srv/public_html/bin/magento cron:run >> /srv/public_html/var/log/cron.log
/usr/local/bin/php /srv/public_html/update/cron.php >> /srv/public_html/var/log/mcron.log
/usr/local/bin/php /srv/public_html/bin/magento setup:cron:run >> /srv/public_html/var/log/mcron.log
```

<font color="red">WARNING: DO not use stdout/stderr redirection "2>&1" as this is already applied with the nice command during execution time.
Adding it may prevent the cron from running entirely. </font>


EXAMPLE: If you have set this cron:
```
/usr/local/bin/php /srv/public_html/bin/magento cron:run >> /srv/public_html/var/log/cron.log
```
the cron that will actually run at execution time will be:
```
/bin/bash -c /usr/share/stratus/cron.sh "nice -n 19 /usr/local/bin/php /srv/public_html/bin/magento cron:run >> /srv/public_html/var/log/cron.log" 2>&1
```

See also <a href="/reference/stratus/guides/magento-2/magemojo-cron/">MageMojo Cron</a>
---
# Stratus Magento 2 Guides - Upgrade Recommendations
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/magento-2-upgrade-recommendations/
Description: Helpful guides for upgrading Magento 2.x can be found on this page. However, support for upgrading your installation to Magento 2 is outside the scope of regular support.



The following are helpful guides for upgrading Magento 2.x.

> Support for upgrading Magento 2 is outside the scope of regular support.

## Before Upgrading

**Perform a local backup of the files and database before upgrading.** Test the upgrade first on a development environment before performing the same steps on production.

* Disable [crons](/docs/reference/stratus/control-panels/cron-panel/schedule/) temporarily
* Put the site in [maintenance mode](/docs/reference/stratus/control-panels/application-panel/maintenance-mode/)

## Notes about Upgrading higher than Magento 2.4.3+

* During _setup:upgrade_ you may get an error related to ServiceManager.php: `Service with name "Magento\Setup\Console\Command\DbStatusCommand" could not be created. Reason: Class "Vertex\Tax\Setup\Schema\Triggers\MigrateVertexInvoiceSent" does not exist`. This is because the Vertex module does not exist in Magento 2.4.4 & higher. You can solve this issue by clearing caches and running _setup:upgrade_ again.

```
redis-cli -h redis flushall && redis-cli -h redis-session -p 6380 flushall && redis-cli -h redis-config-cache -p 6381 flushall;stratus cache.all.clear
```

* During _setup:upgrade_ you may get an error in logs related to DataObject.php: `main.CRITICAL: Deprecated Functionality: Return type of Magento\Framework\DataObject::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /cache/vendor/magento/framework/DataObject.php` In this case you will need to do the following:

1) While PHP version is [set to 7.4](/docs/reference/stratus/control-panels/php-panel/version/): `composer require magento/composer-root-update-plugin ~2.0 --no-update`
2) `composer update`
3) `rm -rf var/cache/* ; rm -rf var/page_cache/* ; rm -rf generated/code/* ; php bin/magento setup:upgrade`
4) `composer require-commerce magento/product-community-edition 2.4.4 --no-update`
5) `composer update`
6) CHANGE TO [PHP 8.1](/docs/reference/stratus/control-panels/php-panel/version/): `rm -rf var/cache/* ; rm -rf var/page_cache/* ; rm -rf generated/code/* ; php bin/magento setup:upgrade`



## Upgrading to a Major Release

To upgrade to 2.2.7 (in this example), *run*:

	composer require magento/product-community-edition 2.2.7 --no-update
	php -d memory_limit=4096M /usr/local/bin/composer update
	php -d memory_limit=4096M /usr/local/bin/composer -v install
	php -d memory_limit=4096M bin/magento setup:upgrade
	php -d memory_limit=4096M bin/magento setup:di:compile
	php -d memory_limit=4096M bin/magento setup:static-content:deploy

For more information, see Magento's [upgrade documentation](https://devdocs.magento.com/guides/v2.3/comp-mgr/cli/upgrade-with-script.html).

## Upgrading to 2.3.x Using the Magento script

	wget https://raw.githubusercontent.com/magento/magento2/2.3/dev/tools/UpgradeScripts/pre_composer_update_2.3.php
	php -f pre_composer_update_2.3.php -- --root=/srv/public_html --repo=https://repo.magento.com/ --version=2.3.3
	php -d memory_limit=4096M /usr/local/bin/composer update
	php -d memory_limit=8000M bin/magento setup:upgrade
	php -d memory_limit=4096M bin/magento setup:di:compile
	php -d memory_limit=4096M bin/magento setup:static-content:deploy

For more information, please see Magento's [upgrade documentation](https://devdocs.magento.com/guides/v2.3/comp-mgr/cli/upgrade-with-script.html).

> If you receive an error about [Magento credentials](https://devdocs.magento.com/guides/v2.3/install-gde/prereq/connect-auth.html), run `composer update`. This will prompt you for your credentials. Choose "_Y_" to save them to your project.

## Upgrading from 2.3.x to 2.4.x

* Ask Stratus Support to upgrade MySQL to a minimum of version 5.7.
* *Enable* Elasticsearch 7 in the STRATUS panel (it will redeploy upon change)
* *Confirm* that PHP is version 7.3+ (it will also redeploy upon change)

		php -d memory_limit=4096M /usr/local/bin/composer require magento/composer-root-update-plugin=~1.0 --no-update
		php -d memory_limit=8000M /usr/local/bin/composer update
		php -d memory_limit=4096M /usr/local/bin/composer require magento/product-community-edition=2.4.3 --no-update --interactive-magento-conflicts
		php -d memory_limit=8000M /usr/local/bin/composer update
		php -d memory_limit=4096M bin/magento setup:upgrade
		php -d memory_limit=4096M bin/magento setup:di:compile
		php -d memory_limit=4096M bin/magento setup:static-content:deploy

## After Upgrading

* Re-enable [crons](/docs/reference/stratus/control-panels/cron-panel/schedule/).
* Take the site out of [maintenance mode](/docs/reference/stratus/control-panels/application-panel/maintenance-mode/).
* Clear all caches
* Perform an [autoscaling reinit](/docs/reference/stratus/guides/webscale-stratus/stratus-cli/#autoscalingreinit/) or ZDD commands if [Zero Downtime Deployment](/docs/reference/stratus/guides/webscale-stratus/zero-downtime-deploys/) is enabled.
---
# Stratus Magento 2 Guides - Using Baler to Speed Javascript Delivery
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/using-baler/
Description: Baler is a module bundler and preloader for Magento 2 installations. It is an open-source add-on that intelligently bundles Javascript based on where and how it is needed.


The result of this bundling is faster page speed times, which can improve customer experiences and Google rankings.

> Bundling can only be activated on a Production environment.

## Installing Baler

To install Baler:

1. *Clone* the current Baler Repository.

	`git clone https://github.com/magento/baler.git`

2. *Change* to the Baler directory and install using npm.

	`npm install`

3. *Check* to confirm you have node.js version 10.12.0 or later.

	`~/baler/bin$ ./baler
	baler requires a version of node.js >= 10.12.0. You're currently using v8.16.0`

	For more on using node.js, see [Node.js Node Version Manager](/docs/reference/stratus/guides/general/node-js-nvm-manager/).

4. *Change* to the Magento 2 document root and run Baler.

	`:~/public_html$ /srv/baler/bin/baler`

5. *Clear* Magento and Redis cache.

	`~/public_html$ n98-magerun2 cache:clean`

	`~/public_html$ n98-magerun2 cache:flush`

	`~/public_html$ redis-cli flushall`

6. *Install* the Magento 2 module that will handle bundlings.

	`composer config repositories.baler vcs https://github.com/adifucan/m2-baler`

	`composer require magento/module-baler:dev-master`

7. *Activate* module.

	`n98-magerun2 module:enable Magento_Baler`

8. *Run* deployment process.

	`n98-magerun2 setup:upgrade`

	`n98-magerun2 setup:di:compile`

	`n98-magerun2 setup:static-content:deploy`

9. *Clear* Magento and Redis cache again.

	`~/public_html$ n98-magerun2 cache:clean`

	`~/public_html$ n98-magerun2 cache:flush`

	`~/public_html$ redis-cli flushall`

10. *Run* the set configuration command.

	`php bin/magento config:set dev/js/enable_baler_js_bundling 1`

11. *Run* Baler again.

	`$ /srv/baler/bin/baler build`

12. *Disable* builtin Magento 2 javascript minification, merging, and bundling.

	`php bin/magento config:set dev/js/minify_files 0`

	`php bin/magento config:set dev/js/enable_js_bundling 0`

	`php bin/magento config:set dev/js/merge_files 0`

13. *Clear* Magento and Redis cache yet again.

	`~/public_html$ n98-magerun2 cache:clean`

	`~/public_html$ n98-magerun2 cache:flush`

	`~/public_html$ redis-cli flushall`
---
# Stratus Magento 2 Guides - Using MagePack to Speed JS Delivery
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/using-magepack/




To successfully utilize [MagePack](https://github.com/magesuite/magepack), a well-known JavaScript bundling tool on Webscale Stratus, please generate magepack.config.js file on your local computer by running a command.
```
docker run -t -i --rm nemke82/magepack-generator bash
```

You can use [Play with Docker](https://labs.play-with-docker.com/) and run docker image directly in your browser tab to generate magepack.config.js file as well.

Run the following to generate magepack.config.js file (Replace https://mystore.com with your domain url ):
```
magepack generate --cms-url="https://mystore.com" --category-url="https://mystore.com/category-2/category-2-1/category-2-1-1.html" --product-url="https://mystore.com/category-2/category-2-1/category-2-1-1/simple-product-122.html"
```

When the file is generated, please upload the file to the docroot of your's Magento 2 installation, [login to the SSH container](/docs/reference/stratus/control-panels/ssh-panel/users/) on Webscale STRATUS environment, and execute:
```
npm install -g magepack
```

At this point tool (magepack) and magepack.config.js file should be successfully installed.

## Requirements

* You need [Node.js version 10 or higher][3] installed.
* If you are using Magento 2.3.5 or lower, you need to have mixins.js module patched ( patch provided and explained here: [Mixins are not applied for bundled modules](https://github.com/magento/baler/issues/23) )
* If you are using Magento 2.3.3 or lower, you need jquery.cookie module shim ( patch provided and explained here: [Invalid shims in Magento core break `core-bundle.js` at runtime](https://github.com/magento/baler/issues/6) )
* You need [Magepack Magento](https://github.com/magesuite/magepack-magento)) module installed. See below for installation instructions.
* You must always use the _"magepack bundle"_ command before _"setup:static-content:deploy"_. Please refer to [Deployment CI/CD scripts][8].

_Note: There is no patch requirement when using Magento 2.4.x_

## Installing MagePack Magento module

It is recommended to install this extension using composer package manager:
```
composer require creativestyle/magesuite-magepack
```

The next step would be to trigger the actual optimization after the static content deploy stage has finished, by running the following in the Magento root directory:
```
magepack bundle
```

This command will iterate over each deployed locale (excluding Magento/blank) and prepare bundles for each of them.

Once you have made sure Magepack Magento module is installed, enable it via the Magento admin panel under _Stores->Configuration->Advanced->Developer_ or CLI:
```
php bin/magento config:set dev/js/enable_magepack_js_bundling 1
```

and clear the caches:
```
php bin/magento cache:clean
php bin/magento cache:flush
redis-cli -h redis flushall && redis-cli -h redis-session -p 6380 flushall && redis-cli -h redis-config-cache -p 6381 flushall
```

Now the store should be way faster than before! You can (and should) even enable all Magento's performance optimizations (except JavaScript bundling of course) for even better results.
---
# Stratus Magento 2 Guides - Terser installation
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/using-terser/
Description: Terser is a JavaScript minifier.


 [Terser](https://github.com/terser/terser) processes JavaScript files as well as the compiled output from other languages like CoffeeScript, and TypeScript and transpilers like Babel.

First, make sure you have installed the latest version of node.js (You may need to restart your computer after this step).

From NPM for use as a command-line app:
```
npm install terser -g
```
Output:
```
$ node -v
v17.3.0

$ npm install terser -g
added 6 packages, and audited 7 packages in 687ms
found 0 vulnerabilities

$ whereis terser
terser: /usr/local/nvm/versions/node/v17.3.0/bin/terser
```

Usage is simple:
[GitHub - terser/terser: JavaScript parser, mangler and compressor toolkit for ES6+ ](https://github.com/terser/terser)

Terser can take multiple input files. It's recommended that you pass the input files first, then pass the options. Terser will parse input files in sequence and apply any compression options. The files are parsed in the same global scope, that is, a reference from a file to some variable/function declared in another file will be matched properly.

If no input file is specified, Terser will read from STDIN.
If you wish to pass your options before the input files, separate the two with a double dash to prevent input files from being used as option arguments:
```
terser --compress --mangle -- input.js
```

In Magento 2 specifically, we can implement the following after setup:static-content:deploy (Static asset) deployment is processed, but before that, we need to know the path of our Theme directory.

For example, let's try now to bundle the default Luma theme on a specific path for en_US language:
```
THEME_FOLDER=('/srv/public_html/pub/static/frontend/Magento/luma/en_US')
```

{{< figure src="/images/stratus/img/articles/terser1.png" alt="helper-75" >}}

Bundle files with the following line:
```
find ${THEME_FOLDER[@]} \( -name '*.js' -not -name '*.min.js' -not -name 'requirejs-bundle-config.js' \) -exec /usr/local/nvm/versions/node/v17.3.0/bin/terser \{} -c -m reserved=['$','jQuery','define','require','exports'] -o \{} \;
```

Note: we skipped some of the patterns like *.min.js and requirejs-bundle-config.js, but if you are using [MagePack](/docs/reference/stratus/guides/magento-2/using-magepack/) or any other popular Bundling tool try to skip their Core bundle files generated. For example, for [Baler](/docs/reference/stratus/guides/magento-2/using-baler/) tool:

-not -name 'core-bundle.js'

You can test and Minify them as well, but our advice is to test this before adding this to your Production environment.

{{< figure src="/images/stratus/img/articles/terser2.png" alt="helper-75" >}}

The last step is to clear Magento 2 cache and Redis if used and test. Run a new audit test, [Measure page quality](https://web.dev/measure/) for example, and compare results before/after

{{< figure src="/images/stratus/img/articles/terser3.png" alt="helper-75" >}}

Disable Magento's built-in Minify mechanism for Javascript minify, integrate this tool in to your deployment process, and enjoy the performance boost.
---
# Stratus Magento 2 Guides - Consumer Brokers MySQL to RabbitMQ.
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/consumers-changing-broker/
Description: The default broker for consumers in Magento 2.3+ is MySQL, with the exception of the async.operations.all consumer which utilizes RabbitMQ. Please check the Webscale STRATUS Patch Repo for easy-to-install patches to switch brokers for Magento consumers to RabbitMQ.


## RabbitMQ vs MySQL

Starting with Magento 2.4.5 Queue Consumers are utilizing RabbitMQ automatically. Any previous versions, when possible, Webscale Stratus recommends using RabbitMQ as the broker instead of MySQL.
The [Magento Dev docs](https://developer.adobe.com/commerce/php/development/components/message-queues/) explain how this can be changed in the env.php file. The RabbitMQ broker provides much better performance than MySQL. We recommend that high traffic sites utilize RabbitMQ for the most often used consumers.

## Webscale Patch Repo

Please check the [Webscale Patch Repo](https://github.com/magemojo/m2-patches/wiki) for easy-to-install patches to switch brokers for Magento consumers to RabbitMQ.

## Manual - Single consumer
The following example is for exportProcessor which is a consumer used for exporting data. By default it uses MySQL as a broker.

1. First confirm that you have RabbitMQ [enabled](/docs/reference/stratus/control-panels/rabbitmq-panel/info/) and [configured](/docs/reference/stratus/control-panels/rabbitmq-panel/configuration/).
2. Find the XML files for the module in question. For exportprocessor, this the Magento 2 core module named ImportExport located in the app/code/Magento/ImportExport/ directory.
    Each of these files will have a piece of information that we will need in our configuration.

    * queue_consumer.xml
    * queue_publisher.xml
    * queue_topology.xml

    queue_consumer.xml contains the consumer _name_
    {{< figure src="/images/stratus/img/articles/con1.png" alt="Instance names-93" >}}

    queue_publisher.xml contains the _publisher topic_
    {{< figure src="/images/stratus/img/articles/con2.png" alt="Instance names-93" >}}

    queue_topology.xml contains the _binding topic_
    {{< figure src="/images/stratus/img/articles/con3.png" alt="Instance names-93" >}}

3. Once you have these pieces of information you can add them to the env.php as follows to switch the RabbitMQ broker for exports:

``` php hl_lines="13 19 35"
'queue' => [
        'amqp' => [
            'host' => 'rabbitmq',
            'port' => '5672',
            'user' => 'username',
            'password' => 'yb2sovjbaa4atsbbn0s0ilovemagemojo',
            'virtualhost' => '/',
            'ssl' => 'false',
            'ssl_options' => []
        ],
        'consumers_wait_for_messages' => 1,
        'topics' => [
            'import_export.export' => [
                'publisher' => 'amqp-magento'
            ]
        ],
        'config' => [
            'publishers' => [
                'import_export.export' => [
                    'connections' => [
                        'amqp' => [
                            'name' => 'amqp',
                            'exchange' => 'magento',
                            'disabled' => false
                        ],
                        'db' => [
                            'name' => 'db',
                            'disabled' => true
                        ]
                    ]
                ]
            ]
        ],
        'consumers' => [
            'exportProcessor' => [
                'connection' => 'amqp'
            ]
        ]
    ],
```

!!! note
    Afterwards you must run _php bin/magento setup:upgrade_ command so Magento 2 can generate a new queue named "export". You will see the following output:
    _2020-11-03 23:05:34.999 [info] <0.8343.0> closing AMQP connection <0.8343.0> (127.0.0.1:38132 -> 127.0.0.1:5672, vhost: '/', user: 'guest')_

Once setup:upgrade has been run, you can view the new queue that has been created with the [rabbitmqadmin command](/docs/reference/stratus/guides/general/configuring-rabbitmq/#advanced-usage/):

``` bash
rabbitmqadmin --host rabbitmq -u username -p ENTER-PASSWORD-HERE list queues name
```

## Manual - Multiple consumers

This Example is for multiple consumers switched to use RabbitMQ.

``` php hl_lines="13 16 22 35 51 54"
'queue' => [
        'amqp' => [
            'host' => 'rabbitmq',
            'port' => '5672',
            'user' => 'username',
            'password' => 'yb2sovjbaa4atsbbn0s0ilovemagemojo',
            'virtualhost' => '/',
            'ssl' => 'false',
            'ssl_options' => []
        ],
        'consumers_wait_for_messages' => 1,
        'topics' => [
            'product_action_attribute.update' => [
                'publisher' => 'amqp-magento'
            ],
            'import_export.export' => [
                'publisher' => 'amqp-magento'
            ]
        ],
        'config' => [
            'publishers' => [
                'product_action_attribute.update' => [
                    'connections' => [
                        'amqp' => [
                            'name' => 'amqp',
                            'exchange' => 'magento',
                            'disabled' => false
                        ],
                        'db' => [
                            'name' => 'db',
                            'disabled' => true
                        ]
                    ]
                ],
                'import_export.export' => [
                    'connections' => [
                        'amqp' => [
                            'name' => 'amqp',
                            'exchange' => 'magento',
                            'disabled' => false
                        ],
                        'db' => [
                            'name' => 'db',
                            'disabled' => true
                        ]
                    ]
                ]
            ]
        ],
        'consumers' => [
            'product_action_attribute.update' => [
                'connection' => 'amqp'
            ],
            'exportProcessor' => [
                'connection' => 'amqp'
            ]
        ]
    ],
```
---
# Stratus Magento 2 Guides - Manually Uninstalling an Extension or Module
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/uninstall-magento-2-extension/
Description: If you're having trouble uninstalling an extension or module from Magento 2 via Composer, you may need to manually uninstall.


> **NOTE:** Before starting any modification that may affect your store, **always** [backup your store and database](/docs/reference/stratus/guides/general/backup-strategies/ "Backup Strategies"/) first. Preferably, you will be performing this action on a Development environment *before* attempting it on a Production environment.

To remove an extension/module manually:

  1. *Log into* the environment via SSH.
  2. *Go to* the root of the Magento 2 installation and remove the folder, `app/code/<Vendor>/<Module>`.
  3. *Run* `n98-magerun2 db:console` to access the database.
  4. *Drop* the module tabels from the database:

	  DELETE FROM core_config_data WHERE path LIKE '<Vendor>_<Module>/%';
	  DELETE FROM setup_module WHERE module='<Vendor>_<Module>';

  (Hint: make sure the database does not have a prefix before running anything.)

  5. *Remove* the module/extension <Vendor>_<Module> from `app/etc/config.php`.

## Uninstalling via Composer

If the extension/module had been installed using **composer**, the procedure, of course, is a lot easier. To recap, from the root of the Magento 2 installation, run:

`php bin/magento module:uninstall --backup-code --backup-db -r -c <Vendor>_<Module>`

## After Uninstalling an Extension

After you have uninstalled an extension or module, you need to run the following command via SSH:

	php bin/magento setup:upgrade
	php bin/magento setup:di:compile
	php bin/magento cache:clean && php bin/magento cache:flush
	php bin/magento indexer:reindex && redis-cli -h redis flushall

> **NOTE:** It is not possible to remove or uninstall default Magento modules if they are not installed with Composer. Many of these are sued as integration modules. However, if you need to cease using a default module, you can simply set it to "disable".
---
# Stratus Magento 2 Guides - Configuring a Sitemap
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/magento-2-sitemap/
Description: A Sitemap is a plain text XML file that contains links to all of the pages on your website. It is used by the search engines to properly crawl and index your website.


To generate a sitemap in Magento 2:

  1. *Go to* **Marketing > Site Map** in the backend of your Magento 2 store.
  2. If you don't already have a sitemap showing in the list, *click* **Add Sitemap**.
  3. *Enter* the filename you wish to use (e.g. "sitemap.xml").
  4. *Enter* the file path from the *root of the Magento install* you wish to have Magento generate the sitemap. Most will simply enter in "/" for the root directory.
  5. *Click* **Save & Generate** to have Magento create your initial sitemap.

  {{< figure src="/images/stratus/img/articles/enable-m2-sitemap-1.png" alt="magento-83" >}}

To configure the parameters of the sitemap:

  1. *Go to* **Stores > Configuration > Catalog > XML Sitemap** in the backend of your Magento 2 store.
  2. *Review* the settings for each subpanel.
  3. *Select* "Yes" for **Generation Settings > Enabled** to have Magento regularly create an updated sitemap. Once you do, you'll see additional settings to configure for start time, frequency, and whether to email an error report to someone.
  4. The final panel you will most likely wish to attend to is the **Search Engine Submission Settings** subpanel. By selecting "Yes" for **Enable Submission to Robots.txt** Magento will insert a link to the sitemap to the site's robots.txt file which instructs search engines what they should and should not index in your site. By linking the sitemap file, you are giving the search engine quick notice of all the pages in your Magento store.
---
# Stratus Magento 2 Guides - Magento 2.4.x Media Gallery
URL: https://docs.webscale.com/docs/reference/stratus/guides/magento-2/magento-2-4-x-media-gallery/
Description: In Magento 2.4.x, merchants can use the an enhanced Media Gallery to organize and manage their media files on the server. This new Media Gallery contains the same functionalities as the existing Media Storage, but includes an improved user interface and a closer integration with Adobe Stock.


You can read more about using the gallery [here](https://experienceleague.adobe.com/docs/commerce-admin/content-design/media/gallery/media-gallery.html).

## Consumer Setup

Full functionality for new Media Gallery requires media.gallery.synchronization and media.content.synchronization queue consumers to be started for initial synchronization.
Configuration in your env.php should look similar to this in order to run these consumers.

    'cron_consumers_runner' => [
            'cron_run' => true,
            'max_messages' => 0,
            'consumers' => [
                'async.operations.all',
                'product_action_attribute.update',
                'product_action_attribute.website.update',
                'exportProcessor',
                'negotiableQuotePriceUpdate',
                'sharedCatalogUpdatePrice',
                'sharedCatalogUpdateCategoryPermissions',
                'quoteItemCleaner',
                'inventoryQtyCounter',
                'media.storage.catalog.image.resize',
                'media.content.synchronization',
                'media.gallery.renditions.update',
                'media.gallery.synchronization',
                'codegeneratorProcessor'
            ]
    ],

## Broker
By default, Magento uses Mysql as a broker for processing consumers. You can gain a significant performance increase by configuring [RabbitMQ](/docs/reference/stratus/control-panels/rabbitmq-panel/configuration/) as the broker for consumers instead.
Please see the [Webscale patch repo](https://github.com/magemojo/m2-patches/wiki#magento2-media-rabbitmq) for instructions.
---
# Stratus Guides - AngularJS
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/angularjs-on-stratus/
Description: AngularJS on Stratus


## server.ts
Locate the server.ts file at the root of AngularJS deployment and edit it to use port 10000. We need port 10000 for anything hosted under the nodejs container.

The block that needs to be modified looks like this. You can comment the default line and simply hard code it.

```
function run() {
  //const port = process.env.PORT || 4000;
    const port = 10000;

  // Start up the Node server
  const server = app();
  server.listen(port, () => {
    console.log(`Node Express server listening on http://localhost:${port}`);
  });
}
```

After this is done we need to compile. Please run:


```
npm run build:ssr
```

## server-side rendering

Once everything is done we need to symlink /srv/pwa directory to our AngularJS application. For example:

```
cd /srv/ ; ln -s /srv/public_html/pub/myappishere/ pwa
```

In this example, we symlinked /srv/pwa to the customer’s myappishere AngularJS directory

Next is based on [STRATUS PWA — PWA Configuration](/docs/reference/stratus/guides/pwa-configuration/) process to create start.sh

```
#!/bin/bash
export NVM_DIR=/srv/pwa/nvm
. "$NVM_DIR/nvm.sh"
cd /srv/pwa
npm run serve:ssr
```

Make sure to set the file as executable:
```
chmod a+rwx start.sh
```

Navigate back to the Stratus panel [NodeJS → Info](/docs/reference/stratus/control-panels/nodejs-panel/info/) section and Start NodeJS container.
After a reboot, NodejS should start:

![Screenshot](/images/stratus/img/articles/nodejs-list.jpg)

The last step is the Nginx portion. The goal will be to host this app under a specific URL or simply switch the entire subdomain or domain to it. [STRATUS Panel - NodeJS > PWA](/docs/reference/stratus/control-panels/nodejs-panel/pwa/)

An example of URL proxy pass that can be added to Nginx includes section safely:


```
location ~ ^(/this/browser) {
proxy_pass http://127.0.0.1:10000;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-SSL-offloaded $ssl_offloaded;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
}
```
---
# Health Checks
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/
Description: HTTP Monitoring | MySQL Alerts | Cron Alerts | High CPU Alerts | High Swap Memory Usage Alerts | High Load Average Alerts | High IO Volume Alerts

---
# Stratus HTTP Monitoring
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alerts-http/
Description: Webscale STRATUS has active HTTP monitoring for sites. Webscale also monitors the root domain, and accepts redirects to avoid duplicate alerts.



> NOTE: For infrastructure level alerts, please subscribe to the [Webscale STRATUS Status page](https://status.magemojo.com/).

## Criteria

Webscale STRATUS has active HTTP monitoring for sites if they meet the following criteria:

* The domain exists in the **[URLs](/docs/reference/stratus/control-panels/domains/urls/ "Urls Control Panel"/)** panel of the Webscale STRATUS environment panel.
* The domain is on a production Webscale STRATUS environment, i.e. not a development environment. Development domains are not monitored.
* A valid **[SSL](/docs/reference/stratus/control-panels/ssl-panel/settings/ "SSL Info Panel"/)** is applied that covers your domain.
* MageMojo have been granted Google Analytics access to validate session usage. Nonvalidated domains are not monitored.
* The domain is not behind a proxy service like Cloudflare or Sucuri.

Webscale also monitors the root domain, and accept redirects to avoid duplicate alerts. *www.example.com* is not directly monitored, but *example.com* would be and, if redirected to www, the last redirect status code is recorded.

If there are additional domains/pages that need to be monitored, there are several third-party services available.

## Alert conditions

Rather than monitoring for every possible failure, our monitoring is focused on identifying system-side issues within Webscale STRATUS. We only monitor the following status codes:

* 502
* 500
* 504

404, 401,403, 503, etc. alerts are ignored. Customers frequently restrict their sites and make changes that cause error responses. Though they are not really causes for alarm.  50x errors are almost always an issue with the code-base, configuration, or the Webscale STRATUS system.

Errors are also **triple checked** before an alert is fired. We exclude certain conditions if detected, such as:

* The site is suspended (sends a 504)
* Services were recently restarted (customer action causing a 504)
* A domain was removed from the URLs list by a customer

## What happens when an alert fires ?

When an alert meets our conditions, the following sequence is triggered:

1. A ticket opens to the environment owner's account and any authorized users are copied on the ticket.
2. Our internal system sends a Slack message to our Support team.
3. A support tech will verify the issue and work to resolve it, with an *Root Cause Analysis* follow up. The RCA will include recommend actions to avoid future outages.
---
# Stratus MySQL Alerts
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alerts-mysql/
Description: Webscale STRATUS will send a MySQL Alert if a store has any query running for over an hour or if there are 5 queries running for more than 10 seconds.


These queries are proactively killed to protect a store from downtime.
* If a store has any query running for over an hour
* If there are 5 queries running for more than 10 seconds

 The alert will contain the queries that were active at the time.

## Common Issues

Below are some common issues seen with Magento databases. Please back up a copy of the database before performing any recommended fixes shown or contact MageMojo Support for assistance.

## Indexer mode
**Indexers set to _update on save_ causing locks**

Please read over our [kb article](/docs/reference/stratus/guides/magento-1/change-index-mode/) on how to fix this issue and what causes it.

## log_
**INSERTS for visitor log tables : log\_url, log\_url\_info, log\_visitor, log\_visitor_info**

Webscale can empty these tables and blackhole them, which is often done on request. Webscale STRATUS customers rarely look at the data in these tables and they cause a large strain on the database due to the large amount of data that is recorded with each customer visit. For prevention, Webscale can perform the following:<br/>

	delete from log_url;
	delete from log_url_info;
	delete from log_visitor;
	delete from log_visitor_info;
	delete from report_event;
	alter table log_visitor engine=BLACKHOLE;
	alter table log_visitor_info engine=BLACKHOLE;
	alter table log_url engine=BLACKHOLE;
	alter table log_url_info engine=BLACKHOLE;
	alter table report_event engine=BLACKHOLE;

## core_cache
**the core_cache table + REDIS + Amasty FPC : core_cache**

The *core_cache* table is being written to, even though Redis is set for backend caching. This is caused by the Amasty Full Page cache.The documentation for configuring Amasty FPC correctly for Redis is in the [Amasty docs](https://amasty.com/docs/doku.php?id=magento_1:full_page_cache#fpc_redis).

## report\_viewed\_product_index
**Report tables: report_viewed_product_index**

This table is used for the recently viewed products. MageMojo can clear and blackhole this table, although if these reports are viewed or there is a "latest products viewed" section on the site, contents of these tables are needed.

	DELETE from report_viewed_product_index;
	ALTER TABLE report_viewed_product_index ENGINE=blackhole;

## core\_url_rewrite
**Magento 1 large table : core\_url_rewrite**

There are bugs within Magento that cause the core_url_rewrite table to over-inflate with duplicate entries. It is definitely recommended to clean flush the table periodically and either let it rebuild on its own, or use a module to rebuild it automatically.

[There are some alternatives discussed online.](https://magento.stackexchange.com/questions/17553/magento-core-url-rewrite-table-excessively-large)

To clear the table:

	TRUNCATE TABLE core_url_rewrite;

## enterprise\_logging_event
**Large table: enterprise\_logging_event**

This table can be truncated and blackholed, however it contains login information for admins. To continue to collect admin logs, do not blackhole this table.

	TRUNCATE TABLE enterprise_logging_event;

## dataflow\_batch_
**Large table: dataflow\_batch\_export, dataflow\_batch\_import**

These tables can be truncated; however, they should not be blackholed. These tables store pre-written results for DataFlow export and import. There is a bug in some versions of Magento where these tables are not truncated appropriately before and after an import/export.

	DELETE FROM dataflow_batch_export;
	DELETE FROM dataflow_batch_import;
	TRUNCATE TABLE dataflow_batch_export;
	TRUNCATE TABLE dataflow_batch_import;

## core_session
**If there are inserts in the core_session table, then MySQL is being used to store sessions.** This is a large strain on the database.

Session storage should be switched to either [Redis or Memcache](/docs/reference/stratus/guides/caches-and-sessions/stratus-sessions-for-magento-1-and-2/). Please contact support if you need assitance.

## sales\_flat\_quote
**sales\_flat\_quote** contains records on every shopping cart created in your store, whether they were abandoned or converted to a purchase. Each row represents one cart. Due to the potential size of this table, many businesses delete records from this table after a certain set of criteria are met (i.e. delete all non-converted carts 60 days after created).

To delete  orders older than 60 days:

	DELETE FROM sales_flat_quote WHERE updated_at < DATE_SUB(Now(),INTERVAL 60 DAY)

## customer_visitor
This table has known to get quite large and slow things down. You can delete all customer data older than 3 days with the following:

	DELETE FROM customer_visitor WHERE last_visit_at < DATE_SUB(NOW(), INTERVAL 3 DAY);

## mst\_misspell_index
This table belongs to the Mirasvit Spellcheck module. There are missing indexes which force MySQL to perform a full table scan which is inefficient. You can add indexes as follows:

	ALTER TABLE mst_misspell_index ADD FULLTEXT INDEX `FullText` (`trigram` ASC);
	ALTER TABLE `mst_misspell_index` ADD INDEX `covered` (`index_id`);
    ALTER TABLE `mst_misspell_index` ADD INDEX `covered1` (`keyword`);
    ALTER TABLE `mst_misspell_index` ADD INDEX `covered2` (`trigram`);
    ALTER TABLE `mst_misspell_index` ADD INDEX `covered3` (`frequency`);

Note: _For MySQL 8, do not place "ASC" at the end of the first query:_

To drop old entries ([idx_frequency] is the name of the index):

	DROP INDEX `idx_frequency` ON mst_misspell_index;
---
# Stratus Cron Alerts
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alerts-cron/
Description: Webscale STRATUS will send a *Cron Health Alert Notice* if a store has more than 10 crons running simultaneously.



Excessive crons are proactively killed to protect a store from downtime. If the store is Magento 2, please be sure that the [MageMojo Cron module](https://github.com/magemojo/m2-ce-cron) is installed.
---
# Stratus High CPU Alerts
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alert-cpu/
Description: Webscale STRATUS will send a high CPU Alert Notice if a store is experiencing a high amount of CPU usage.


 The percentage of the allowed limit will be included.
To maintain accessibility to your server, Webscale STRATUS will restart services on your store.
---
# Stratus High Swap Memory Usage Alerts
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alerts-mem/
Description: Webscale STRATUS will send a High Swap Memory Alert if a store is experiencing high swap memory usage.



 The amount exceeded will be included in the alert.

To maintain accessibility to your server, Webscale STRATUS will restart services on your store.
---
# Stratus High Load Average Alerts
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alerts-load/
Description: Webscale STRATUS will send a High Load Average Alert if a store is experiencing high load.


To maintain accessibility to your server, Webscale STRATUS will restart services on your store.
---
# Stratus High Input/Output (I/O) Volume Alerts
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/alerts-io/
Description: Webscale STRATUS will send a High Input/Output (I/O) Volume Alert if a store is exceeding 250,000 calls per second.


 To maintain accessibility to your server, Webscale STRATUS will terminate this activity.  
---
# Stratus Billing Breakdown
URL: https://docs.webscale.com/docs/reference/stratus/billing/bill-breakdown/
Description: Billing in Webscale STRATUS is designed to be simple and predictable.


Although Webscale STRATUS is built on top of many Amazon services, which each have their own individual pricing schemes, our pricing is reduced to only these values.


 1. A regular monthly payment of a base price.
 2. A small charge per session for sessions over the plan limit. See [How Sessions are counted](/docs/reference/stratus/billing/stratus-billing/) for details.
 3. A charge of the average GB of storage used over the allowed storage per month. See [Billing Breakdown](/docs/reference/stratus/billing/bill-breakdown/#storage/) for details.
 4. The addition of any [other addons](/docs/reference/stratus/billing/bill-breakdown/#addons/) that have been purchased.

Through this simple system, server costs are reduced to only what is used each month. As a business grows, it can scale predictably and seamlessly.

## Base Fee

A regular monthly payment of a base price depending on the [plan](https://www.webscale.com/stratus/).

## Sessions

A small charge per session is added for sessions in excess of the selected [plan](https://www.webscale.com/stratus/). A default session is counted as one IP address per hour excluding well-known bots. For further details please see [Stratus Billing](/docs/reference/stratus/billing/stratus-billing/). Sessions are not charged on [development environments](/docs/reference/stratus/about-webscale-stratus/environment-types/#development-environments/).

## Storage

We sample storage used once per day. Storage use includes the __primary environment, all associated dev environments and backups__. At the end of the billing cycle we average the amount, then subtract your [included storage](https://magemojo.com/pricing.php) for a final amount.

*Example:*

|dated     |usage|dated     |usage|dated     |usage|
|----------|-----|----------|-----|----------|-----|
|2020-01-01|102  |2020-01-12|90   |2020-01-23|100  |
|2020-01-02|102  |2020-01-13|93   |2020-01-24|100  |
|2020-01-03|102  |2020-01-14|93   |2020-01-25|100  |
|2020-01-04|103  |2020-01-15|93   |2020-01-26|100  |
|2020-01-05|103  |2020-01-16|93   |2020-01-27|102  |
|2020-01-06|103  |2020-01-17|93   |2020-01-28|102  |
|2020-01-07|90   |2020-01-18|93   |2020-01-29|90   |
|2020-01-08|90   |2020-01-19|100  |2020-01-30|90   |
|2020-01-09|90   |2020-01-20|100  |2020-01-31|90   |
|2020-01-10|93   |2020-01-21|100  |
|2020-01-11|93   |2020-01-22|100  |

Sum of daily storage / # of days in billing cycle

	2993 / 31 = 96.548 (97G)

Subtract included storage (pro in this example)

	97 - 75 =  22G

Multiply times rate (pro in this example)

	22 x 0.47 = $10.34

## Addons

* <a href="https://www.webscale.com/solutions/cloudedge-cdn/">CloudEdge CDN</a>
* <a href="https://www.webscale.com/solutions/cloudedge-security/">CloudEdge Security</a>
* <a href="https://www.webscale.com/solutions/cloudedge-pwa/">CloudEdge PWA</a>
* CloudEdge Redirector
* Cloudfront bypass
* ElasticSearch
* Magento One Patching
* API Calls<BR>
&nbsp;
---
# Billing
URL: https://docs.webscale.com/docs/reference/stratus/billing/


---
# Stratus Billing - Sessions
URL: https://docs.webscale.com/docs/reference/stratus/billing/stratus-billing/
Description: Stratus has a small charge per session for sessions over the plan limit.


## How Sessions are Counted

The free sessions based off your plan are deducted from the monthly total, divided by 200, rounded up and then added to the invoice by that quantity.

Sessions are quantified by unique ip address and user agent with the following considerations

* Session has at least 2 hits
* A new session for a ip / user agent combo has < 1 hour between hits

Excluded from any calculations:

* Hit to root uri “/”
* User agent is in bot list
* static assets, images. js, css etc.
* Total remaining hit count = 1, there must be two qualifying hits for a session to be considered
* Errors are quantified by any status code > 400 and do not count in any other metric
* Api Hits are quantified by a uri matching regex expression (/rest|/api)
method is not equal to GET, only functions that change data are counted

## Bots Detection
 Bots are detected by user agent as legitimate bots will follow certain patterns that are attempting to hit the robots.txt file. These user agents are then added to the bots list

* user_agent contains “Mozilla” and user_agent contains “http”
* user_agent contains “Mozilla” and user_agent contains “compatible”
* user_agent does not contain “Mozilla”


## LEGACY configuration with GA
<font color="red">Configuration for Google Analytics session collection has been discontinued. You may continue to use this method however in place of local session calculation from logs until [July 2023][10] on plans that were purchased before May 9th, 2022</font>

You can find this method [HERE](/docs/reference/stratus/billing/stratus-billing-ga-legacy/).
---
# Stratus Environment terms
URL: https://docs.webscale.com/docs/reference/stratus/billing/environment-terms/
Description: On 11-18-2021, STRATUS MaaS became Webscale STRATUS and introduced a new billing and term options.



By committing to a 1-year term, you can save 20% on your current pricing and receive Webscale STRATUS Vitals for 12 months at no extra cost (a $4,200 value!). You may also commit to a 2-year term, save 25% on your monthly bill, and receive Webscale STRATUS Vitals for 12 months.

#### What does this mean for me?
You will continue receiving the same great price, technology, and support that you know and love. By committing to a 1-year term, you can save 20% on your current pricing and receive [Stratus Vitals](/docs/reference/stratus/control-panels/general-panel/stratusvitals/) for 12 months at no extra cost (a $4,200 value!). You may also commit to a 2-year term, save 25% on your monthly bill, and receive [Stratus Vitals](/docs/reference/stratus/control-panels/general-panel/stratusvitals/) for 12 months. Both 1-year and 2-year terms are still paid monthly. Month-to-Month is still an option with a 20% price increase.

#### What do I have to do?
Simple. Upon login, you will be prompted to select a term for each active Stratus environment under your account. That’s it! Once you’ve completed your selection, your service will continue, uninterrupted.

#### Anything else I should know?
Yes! You might have noticed some recent changes to your Stratus Admin panel. We have been working diligently to provide a smoother, efficient, and more organized Stratus experience. You will be able to clearly see all of your active Stratus environments as never before and easily perform administrative functions. What’s even better? You still have the vastly powerful Stratus technology stack powering your site.

Thank you for continuing to trust us with your hosting needs. Remember, we are giving [Stratus Vitals](/docs/reference/stratus/control-panels/general-panel/stratusvitals/), free of charge for 12 months, to all that sign up for a 1-year or 2-year term. Stratus Vitals is an application performance monitoring toolset to give you deep insight and clear visibility into how your environment is performing.
---
# Stratus - Upgrading and Downgrading
URL: https://docs.webscale.com/docs/reference/stratus/billing/upgrading-and-downgrading/
Description: Upgrading and Downgrading.


* You may not downgrade an environment to a plan that is lower than the original commitment.
* You may upgrade to a higher plan level with a minimum 1 month commitment. You may downgrade freely after being upgraded as long as it is to the original or higher level plan
* You are free to swap plans, ie you have a starter and a lite, you may move the environments and make the starter the lite and vise versa. You may not downgrade any of your plans in the process.
---
# Stratus Credit card or billing failure
URL: https://docs.webscale.com/docs/reference/stratus/billing/credit-card-failed-notice/
Description: When the Webscale STRATUS billing system attempts to collect a monthly payment, if it fails, a special notice is emailed.


Typically, refused payment is due to the credit card being expired or a fraud hold from the card issuer.

> Other than verifying what card was attempted, our system can only see that failed. If the card in your MageMojo.com customer account is correctly entered, please check with the bank or card issuer regarding the failure.

If the bank or issuer says there are no issues, please contact Webscale STRATUS Billing Support.

&nbsp;
---
# Stratus - Retrying payment
URL: https://docs.webscale.com/docs/reference/stratus/billing/retry-payment-or-force-payment/
Description: You can retry a payment through your Webscale STRATUS customer account.



1. *Log into* MageMojo.com.
2. *Go to* then go to **Billing**.
3. *Select* the appropriate *Service*.
4. *Click* **Retry Payment**.

![Service Payment Retry](/images/stratus/img/articles/billing-retry-1.png "Service Payment Retry")

You will receive a message indicating the success or failure of the retry.
---
# Stratus - Update Credit Card
URL: https://docs.webscale.com/docs/reference/stratus/billing/update-your-credit-card-information/
Description: If a payment fails or the method of payment needs to be updated



1. *Log into* your customer account at [webscale.com/stratus/magento/customer/account/login/](https://webscale.com/stratus/magento/customer/account/login/).
2. *Go to* **Billing** and *scroll down* to **My Payment Profiles**.
3. *Click* **Add Payment Method**.

	> Note that an existing payment method may not be edited. To update a card, you should *add* a new payment method, then re-assign the new method to the billing profile).

4. *Enter* the card information.
5. *Click* **Submit** to save the card information.
6. *Find* the appropriate Service at the top of the **Billing** screen.
7. *Select* the new payment profile under **Billing Profile**.
---
# Cancelling Stratus Service
URL: https://docs.webscale.com/docs/reference/stratus/billing/cancelling-hosting-service-server/
Description: To cancel an existing Webscale STRATUS service


*Log into* the MageMojo customer account and place a ticket with billing.

Please refer to the [Master Services Agreement](https://www.webscale.com/msa/) if you are on a yearly term.

Any cancelled service will be shut down the following night. Data will be immediately eligible for deletion. We make no guarantees of data retention after the moment a cancellation is submitted. Please ensure that all necessary data and backups have been completed before cancelling.

> If the server is needed to the end of the billing period, please do not cancel until just before the next payment date.
---
# Stratus Billing - Legacy GA Session collection
URL: https://docs.webscale.com/docs/reference/stratus/billing/stratus-billing-ga-legacy/
Description: LEGACY configuration with Google Analytics


<font color="red">Configuration for Google Analytics session collection has been discontinued. You may continue to use this method however in place of local session calculation from logs until [July 2023][10] on plans that were purchased before May 9th, 2022</font>

Note: In order for your domains to be validated, the following must be met:

  1. The Domain Name Server (DNS) for the domain must be pointed to STRATUS, either via Route 53 nameservers or the proper CloudFront Distribution CNAME
  2. The domain must load in a browser and it must use an HTTPS SSL certificate as required by Cloudfront
  3. The domain must NOT be protected by HTTP Auth, Full IP restriction or block the country of the United States.
  4. A Google Analytics code must be detected on the domain
  5. Our billing system must be able to access Google Analytics data for the specific domain.

First, *create* a [Google Analytics account](https://support.google.com/analytics/answer/1008015?hl=en "Get started with Analytics"), if not already created.

Once the account is created, configure the Magento install and Google Analytics for optimized tracking.

<strong>Adding a GA code to a Magento 1 Store</strong>

See [Best ways to set up GA in Magento 1 from Shero Commerce](https://sherocommerce.com/5-best-ways-to-configure-magento-google-analytics-reporting/) for configuration of a Magento store and Google Analytics.

<strong>Adding a GA code to a Magento 2 Store</strong>

For Magento2, see [Enabling GA in Magento 2](https://docs.magento.com/user-guide/marketing/google-universal-analytics.html)

For the newer Ga4 Analytics codes, you may have to add the provided code snippet under Content-> Design - Configuration -> YOUR THEME -> HTML HEAD -> Scripts & Style sheets
	![GA4 header](/images/stratus/img/articles/magentoworks.png "GA4 header")

### GA code types

  Stratus Billing supports 2 types of GA codes. <font color="red">Configuration for Google Analytics session collection has been discontinued. You may continue to use this method however in place of local session calculation from logs until [July 2023][10] on plans that were purchased before May 9th, 2022</font>

  * Universal codes: (ex. UA-1111111) Sites using these codes may use [Legacy Authorization] OR [oAuth Validation] for their GA account for billing access. The default setting is currently on Legacy. If you would like to use oAuth Validation instead, please let our support team know so we can switch the Validation type for your account.

  * GA4 codes: (ex. G-1111111) Sites using GA4 codes can only be validated via [oAuth Validation]. The default setting is currently on Legacy authorization. Please let our support team know if you are using one of these codes, so we can switch the validation type for your account to oAuth.

    > Note: You will need to make sure that all domains on the store use the same type of GA code. A mixture of GA types will result in your domains being unable to validate. ALL domains must use Universal GA codes (ex. UA-111111)
    OR
    ALL domains must use GA4 codes (ex. G-111111).

### GA Grant MageMojo access

Access must be allowed for Magento so that the stratus billing system can obtain session data from the Google Analytics account. How you grant access depends on which type of GA code you are using and which type of Authorization. <font color="red">Configuration for Google Analytics session collection has been discontinued. You may continue to use this method however in place of local session calculation from logs until [July 2023][10] on plans that were purchased before May 9th, 2022</font>



#### GA Legacy Authorization

Grant access for Universal codes only as follows:

1. *Log into* the customer account on MageMojo.com.
2. *Click* on **STRATUS**.
3. *Choose* the correct STRATUS project and environment
![GA Code Panel](/images/stratus/img/articles/ga-choose-env.png "GA Choose environment")
4.  *Click* on *Domains -> URLs* & copy the email address, similar to *stratus-22@stratus-173717.iam.gserviceaccount.com*.

	![GA Code Panel](/images/stratus/img/articles/ga-billing.png "GA Code Panel")

5. *Go to* <a href="https://analytics.google.com/analytics/web/#home/" target="_blank">https://analytics.google.com/analytics/web/#home/</a>.
6. *Click* on the correct view for the STRATUS store.
7. *Click* **Admin Gear Icon** in the lower left.
![GA gear](/images/stratus/img/articles/ga-gear.png "GA gear")
8. *Click* **Account Access Management**.
	![Account Access Management](/images/stratus/img/articles/ga-menu.png "Account Access Management")
9. *Click* the blue **+** icon and *select* **Add Users**.

	* **Email Address** — *Enter* the GA Account email address noted above.
	* **Permissions** — *Select* "Analyst".
	![Add User Panel](/images/stratus/img/articles/ga-email.png "Add User Panel")

10. *Click* **Add**.
11. *Log into* the customer account on MageMojo.com.
12. *Click* on **STRATUS**.
13. *Click* the desired STRATUS environment to expand the environment details.
14. *Click* Domains > URLs in the panel.
15. *Click* **Validate**.

  ![button](/images/stratus/img/articles/validatebutton.png "button")

After validation and go live, you will start to be charged based on session usage from your Google Analytics account.

> **Please note** Default session counting from your site logs will be used if Google Analytics codes are not present or validated on your domains.
These session counts currently exclude well-known bots. A session is counted as one IP address per 20 minutes.


#### GA OAuth Authorization

Grant access for [GA4][8] codes or [UA] codes as follows:

1. *Log into* the customer account on MageMojo.com.
2. *Click* on **STRATUS**.
3. *Click* the desired STRATUS environment to expand the environment details.
4. *Click* Domains > URLs in the panel.
5. *Click* **Validate**. A window will launch asking you to allow Stratus access to your Google Analytics account.

  ![button](/images/stratus/img/articles/validatebutton.png "button")

After validation and go live, you will start to be charged based on session usage from your Google Analytics account.

> **Please note** Default session counting from your site logs will be used if Google Analytics codes are not present or validated on your domains.
These session counts currently exclude well-known bots. A session is counted as one IP address per 20 minutes.

### GA Block Known Bots

Since MageMojo charges customers based on user sessions, it's important that you filter known bots and spiders from Google Analytics so that your session usage is as accurate as possible.

To set Google to filter known bots:

1. *Log into* your Google Analytics account.
2. *Go to* **Admin**.
3. In the View column, *click* **View Settings**.
4. *Select* **Bot Filtering > Exclude all hits from known bots and spiders**.
5. *Click* **Save**.

> Note that your session charges may not be adjusted or refunded if you do not set Google to filter known bots.

### GA Troubleshooting

<font color="red">Configuration for Google Analytics session collection has been discontinued. You may continue to use this method however in place of local session calculation from logs until [July 2023][10] on plans that were purchased before May 9th, 2022</font>

* **I receive the error message *Domain does not appear to be live, incorrect DNS resolution.* when I attempt to validate** <br>
This means the domain is not yet pointed to stratus.

* **I receive the error message *Google Analytics Code not found* when I attempt to validate** <br>
The domain is live, but we are unable to find a reference to a GA tracking code on the page.

* **I receive the error message *Unable to connect to Google Analytics View* when I attempt to validate** <br>
The tracking code is found in the page, but the API access to the GA code is denied. The following conditions can cause this error:

- Authorization has not been granted for the correct email address.<br>
- You are attempting to validate a [GA4][8] code with Legacy Authorization.<br>

* **How can I see which GA codes are on my site?** The best way to see GA codes is by using [Google Tag Assistant](https://chrome.google.com/webstore/detail/tag-assistant-legacy-by-g/kejbdjndbnbjgmefkgdddjlbokphdefk) in Chrome. If Google Tag Assistant can't see the code, then neither can the billing system.

* **504 or timeout when attempting to validate.** The following conditions can cause this error.

- All domains on a store must use the same type of GA code. A mixture of GA types will result in your domains being unable to validate. ALL domains must use Universal GA codes (ex. UA-111111) OR ALL domains must use GA4 codes (ex. G-111111).<br>
- All domains on a store must have GA codes that use the *same* email address for authorization.
- If you have several domains in a multistore environment, a timeout will occur if the billing system can not verify all domains within 180 seconds. If this occurs, it does not necessarily mean that any of your domains are invalidated. Please send in a ticket to support for confirmation if you are unsure of your environment's status.

* **I have multiple environments and I can only keep one validated**
If you have multiple production environments and you use oAuth authorization, each account must be authorized with a different gmail account.

* **I need to remove Stratus Permissions or re-add it, how can I do so?**
Go to this page for the Google Account: https://myaccount.google.com/security in question. Scroll down to the *“Third-party apps with account access”* section. Remove the Stratus app that was authorized previously. You may reauthorize it from the Stratus Control panel URL page.
---
# Hosting Support
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/
Description: Support Policy | How to Contact | Customer Accounts | How Migrations Work | Remote MySQL Access | Load Testing | Clearing Browser Cache | Taking Screenshots | Magento Patches | Bulk Email | Changing Account Ownership | Logs | Using MTR | FAQ

---
# Webscale Stratus Customer Accounts
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/magemojo-customer-accounts/
Description: Steps to set up your customer account on the Webscale STRATUS portal and how to manage it.



# Customer accounts

Welcome to Webscale STRATUS, the fastest hosting you can find for Magento. But as with Magento, not everything can be simple and there are many things specific to our hosting that may not be obvious at first. Never fear, this guide and KB is here to help, but you can always contact <support@magemojo.com> to work with our staff directly.

## Accounts and access at Webscale STRATUS

After your initial order, we will provision your server, which can take several hours, and longer if there is a site migration involved.  Once provisioning is complete, you will see an entry under your customer login at MageMojo.com.  This login we will refer to as the **account owner** or customer account and it uses the same email you ordered your server under.  To log into your customer account, go to <https://magemojo.com/magento/customer/account/login/>

If you have forgotten your password, please use the forgotten password link.

Upon login, you should see a screen with some information about your account, such as recent billing, and multiple menu items.  The two areas you will use the most are **My Tickets **and **My Servers**<figure id="attachment_2555" aria-describedby="caption-attachment-2555" style="width: 100%" class="wp-caption alignnone">

{{< figure src="/images/stratus/img/articles/customer_acct.png" alt="customer accounts-72" >}}

## Overview (My Dashboard)
The main login page at MageMojo.com

* Recent orders
* Account Information: A quick view of your profile information.
* Address Book: A quick view of addresses you have with us.

## Webscale STRATUS
All Webscale STRATUS environments are listed here along with:

* Status including GA code validation if applicable
* Stratus Control panel
* The authorized user list
* Current DNS information

## Tickets
Enter our Helpdesk portal and request support here.

## Profile
Here you can set the name on the account and email address. **Note** that if you change the email address your login username also changes, since it is the email address itself.

## 2fa
This is where you can set up Two-factor authentication for your Webscale STRATUS account's security.

## Billing
Payment profiles let you configure what credit card and billing information you use to pay for a given service.  If you only have one server under an account, this can be used to swap through various cards, otherwise, it is meant for our customers managing multiple servers.

## Invoices
If you need a list of past charges and orders, visit this area. Each order can be selected individually by clicking on the order number. PDF invoices are also available after selecting the order.

## Affiliate
Webscale offers affiliate commissions, if you have referred other customers to us, then you can view your current balance here.

## Addresses
For users with multiple servers at Webscale STRATUS, this lets you manage various billing addresses.
---
# Webscale One - How Migrations Work
URL: https://docs.webscale.com/docs/reference/how-migrations-work/
Description: Webscale provides initial migration services for new clients. The migration service moves your current site to Webscale One and helps with configurations to make sure it is ready to launch.


## Preparation

After a new Webscale One environment is provisioned, an email is sent to the owner requesting information needed for the migration task:

* Domain(s) to be migrated
* Path to files on current host (e.g. /var/www or /home/username/www)
* Control Panel URL
* Control Panel Username
* Control Panel Password
* SSH URL
* SSH Username
* SSH Password


> Depending on the current hosting, store owners may not have immediate access to all the needed information. The owner should consult with their original developers or the hosting provider asssistance.

At a minimum, Support needs SSH access to dump the store database and sync the site files between the servers. Alternatively — but much less desirable — Support can use a pre-made archive. Many Admin panels, such as cPanel can create such archives.

## Initial Migration

Once Webscale support has verified access to the current environment, the migration team will:

* Dump the existing database(s) to a file
* Sync the files and database dump to the new environment
* Copy any SSL certificates that can be accessed
* Copy any extra frameworks/databases detected such as WordPress blogs
* Setup and import the database on Webscale One
* Configure any extra domains or store codes
* Set the base URLs and cookies to a temporary domain
* Confirm the site loads
* Review basic site functionality
* Turn off all cron jobs until the site goes “Live.” You can test cron jobs manually via SSH.
* Change any custom symlinks to reflect available folders under /srv/ (like /mnt, /glusterfs)  
* Activate Redis cache, Redis session, and Varnish for Full Page Caching (for Magento 2 stores).
* Change any relative symlinks to absolute. (ex.. ../../../env.php to /srv/public_html/app/etc/env.php)

After confirming the site appears to be working as expected, and Webscale Control Panel access is sent, Webscale will request testing by the store owner and/or developers.

## Review and Testing

The purpose of the review period is to make sure everything you need is working for your store. The site should be tested as it would normally be used. Any business critical custom scripts or cron tasks should be tested.

During the review and tesing, Webscale recommends the following minimum testing actions be completed:

  * Check categories, product pages, and search results.

  * Add a product to the shopping cart.

  * Verify coupons and special pricing rules.

  * Verify the Magento Admin login process.

  * Check for any Magento extensions that require licenses. Make sure extensions are functioning and do not need an updated license.


## Final Switchover

Once the review and testing is accepted and confirmed by the store owner, Webscale Support will request a time for the final switchover. During this final step, the support team will:

  * Set maintenance mode on the previous site to prevent orders
  * Resync the database with a fresh copy from the previous host
  * Clear any cache


Once the domain is pointed to your new environment, the site will then appear live, but due to DNS propagation, this may not be immediate.  

> NOTE: It is recommended to schedule the final migration for a low traffic/off-hours time to minimize impact to your customers.
---
# Stratus Remote MySQL Access
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/can-i-access-mysql-remotely/
Description: For security reasons, access to MySQL on STRATUS is available only via [SSH tunnel](/docs/reference/stratus/guides/ssh-and-sftp/ssh-tunnels/).



 Direct access via *hostname:port* cannot be made available.
---
# Load Testing Webscale Stratus
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/can-i-load-test-stratus/
Description: Due to the auto-scaling and distributive architecture of Webscale STRATUS, load testing requires careful attention. Since all Webscale STRATUS traffic is routed through a CDN, excessive traffic could be seen as malicious traffic and blocked from any access.


Take a look at our <a href="https://www.webscale.com/support/#support-packages">Application Load Testing</a> addon.

Customers purchasing the production-level load testing above should be aware that:

* Load testing will impact billing. Google Analytics and local session counts may report a large increase in user sessions which will be charged as part of the STRATUS billing.
* Production testing will limitlessly auto-scale the environment on the web front end (PHP). The database will quickly become the bottleneck, usually due to row level locks.

> Customers will be responsible for any billing charges incurred as a result of the increased traffic demands of the testing scenarios.

> Catalog Search paths are rate limits by IP and cannot be altered due to their susceptibility to malicious attacks.
---
# Clearing Browser Cache
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/clearing-browser-cache/
Description: The browser cache is a temporary storage location on a computer for files downloaded by a browser to display websites. Here are the steps to follow if If Webscale STRATUS Support recommends clearing your browser cache.



 Some of the files a browser will store are:

  * Images
  * HTML
  * CSS
  * JavaScript
  * Cookies

Sometimes, especially when testing for changes on a store, the browser will display content from its cache storage rather than retrieve a new version of the asset files from the server. In these cases, it may be necessary to *clear* the browser cache.

If Webscale STRATUS Support recommends clearing your browser cache, refer to these instructions.

> Please note that browser are often updated. These instructions may be slightly different as updates occur.

## Google Chrome

1. *Click* the **Menu** button just to the right of the website address bar (the vertical *ellipsis* icon).

2. *Go to* **More Tools > Clear Browsing Data…**

	{{< figure src="/images/stratus/img/articles/chrome1.png" alt="Chrome-47" >}}

	*Select*:
	* Browsing history
	* Download history
	* Cached images and files
	* Cookies and other site data

	{{< figure src="/images/stratus/img/articles/chrome2.png" alt="Chrome-95" >}}

3. *Click* **CLEAR BROWSING DATA**

## Mozilla Firefox

1. *Click* the **Menu** button just to the right of the website address bar (the *horizontal stripes* or *hamburger* icon).

2. *Go to* **Preferences > Privacy & Security**

3. In **Cached Web Content**, *click* **Clear Now**.

	{{< figure src="/images/stratus/img/articles/ff1.png" alt="ff-4" >}}

## Mozilla Firefox Quantum

1. *Click* the **Menu** button just to the right of the website address bar.

2. *Go to* **Library > History > Clear Recent History**

	{{< figure src="/images/stratus/img/articles/ffnew.png" alt="ff-55" >}}

3. *Select* the following and *click* **Clear Now**.

	{{< figure src="/images/stratus/img/articles/ffnewb.png" alt="ff-86" >}}

## Internet Explorer 10 &11

> **NOTE:** it is strongly recommended that Explorer not be used as a browser.

1. *Click* the **Menu** cog icon just to the right of the website address bar.

2. *Go to* **Internet Options**

	{{< figure src="/images/stratus/img/articles/ie11.png" alt="ff-38" >}}

3. *Click* **Delete…**

	{{< figure src="/images/stratus/img/articles/ie11b.png" alt="ff-12" >}}

4. *Select* the following and *click* **Delete**

	{{< figure src="/images/stratus/img/articles/ie11c.png" alt="ff-63" >}}

## Microsoft Edge

1. *Click* the **Menu** button just to the right of the website address bar.

2. *Go to* **Settings > Choose What to Clear**.

	{{< figure src="/images/stratus/img/articles/edge.png" alt="ie-24" >}}

3. *Select* the following and *click* **Clear**.

	{{< figure src="/images/stratus/img/articles/edge2.png" alt="ie-80" >}}

## Safari

1. *Click* **Safari** in the menu.

2. *Go to* **Preferences…**

	{{< figure src="/images/stratus/img/articles/safari.png" alt="safari-45" >}}

3. *Click* the **Privacy** tab.

4. *Click* **Remove All Website Data**.

## Opera

1. *Go to* the **Menu** at the top left.

2. *Click* **Settings**.

	{{< figure src="/images/stratus/img/articles/opera.png" alt="opera-13" >}}

3. *Go to* **Privacy & Security > Clear Browsing Data**

	{{< figure src="/images/stratus/img/articles/opera2.png" alt="opera-4" >}}

4. *Select* the following and *click* **Clear browsing data**

	{{< figure src="/images/stratus/img/articles/opera3.png" alt="opera-100" >}}
---
# Taking Screenshots
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/how-to-take-a-screenshot/
Description: Screenshots of error messages and other events can help Webscale STRATUS Support more quickly diagnose issues.


 However, taking a screenshot via a phone camera is *not* recommended or preferred. These photos are very often blurry or sent to support embedded in a Word document. In either case, they are generally not usable.

> Taking a screenshot from a computer desktop is preferred and the improved clarity greatly beneficial to support.

Once you capture a screenshot, you may include it as an attachment to a Support Ticket.

> **NOTE:** do **not** add the image to a Word or Pages document. Attach only the image file to the support ticket.

## Screenshots by Operating Systems

For help in taking clear screenshot images based on operating system:

* **Windows** — [Use Snipping Tool to capture screenshots](https://support.microsoft.com/en-us/help/13776/windows-10-use-snipping-tool-to-capture-screenshots "Use Snipping Tool to capture screenshots")
* **MacOS** — [Take a screenshot on your Mac](https://support.apple.com/en-us/HT201361 "Take a screenshot on your Mac")
* **Linux** — [Screenshots and screencasts](https://help.ubuntu.com/stable/ubuntu-help/screen-shot-record.html "Screenshots and screencasts")

## Other Screenshot Tools

Other screenshot tools to consider:

* **Awesome Screenshot** — a [Chrome extension](https://www.awesomescreenshot.com/ "Awesome Screenshot").
* **Skitch** — an [Evernote product](https://evernote.com/products/skitch "Skitch").
---
# Known Magento Patches
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/magento-2-patches/
Description: All RabbitMQ patches for Magento 2 are located in the Webscale STRATUS Patch Repo.


## RabbitMQ patches

All RabbitMQ patches for Magento 2 are located in the [Webscale STRATUS Patch Repo](https://github.com/magemojo/m2-patches).

**Magento2-Import-Export-RabbitMQ:**

Convert consumers broker from MySQL to RabbitMQ for:

* exportProcessor

**Magento2-Catalog-RabbitMQ:**

Convert consumers broker from MySQL to RabbitMQ for:

* product_action_attribute.update
* product_action_attribute.website.update

**Magento2-Media-RabbitMQ:**

Convert consumers broker from MySQL to RabbitMQ for:

* media.content.synchronization
* media.storage.catalog.image.resize
* media.gallery.synchronization
* media.gallery.renditions.update

**Magento2-Inventory-RabbitMQ:**

Convert consumers broker from MySQL to RabbitMQ for:

* inventory.source.items.cleanup
* inventory.mass.update
* inventory.reservations.cleanup
* inventory.reservations.update
* inventory.reservations.updateSalabilityStatus
* inventory.indexer.sourceItem
* inventory.indexer.stock




## Patches Affecting Multiple Versions

**2.3.3-p1-2.3.7-p2** and **2.4.0-2.4.3-p1**

This patch resolve a vulnerability rated critical. Successful exploitation could lead to arbitrary code execution. Read more about this vulnerability at [Adobe](https://support.magento.com/hc/en-us/articles/4426353041293-Security-updates-available-for-Adobe-Commerce-APSB22-12-) & [Sansec](https://sansec.io/research/magento-2-cve-2022-24086). Located in the [MageMojo Patch Repo](https://github.com/magemojo/m2-patches) under <em>Magento2-MDVA-43395-Security-Patch</em> and <em>Magento2-MDVA-43443-Security-Patch</em>

**2.4.x**

Patch to fix PDO Adapter when MySQL 8.0 is used for Temporary tables using LIKE SQL query. Located in the [MageMojo Patch Repo](https://github.com/magemojo/m2-patches) under <em>Magento2-Framework-PDO-Adapter-MySQL8</em>

**2.3.6, 2.4.1**

"Create an Account" button on the Create New Account page remains disabled if a shopper has entered invalid data. This prevents shoppers from re-attempting to create an account after making an error. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>MC-38509 Create New Customer Account patch</em>

**2.1.x, 2.2.x, 2.3.x**

Fix disclosure of URL location of a Magento Admin panel. https://magento.com/security/security-update-potential-vulnerability-magento-admin-url-location
Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>PRODSECBUG-2432</em>

**2.3.1, 2.3.2**

Async/Bulk REST APIs only support the default store view scope patch. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>Scope parameter for Async/Bulk API patch</em>

## Single Version Patches

**2.4.0**

Can not access the Braintree Settlement Report page patch. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>BUNDLE-2683 Braintree Settlement Report patch</em>

Magento throws an error when opening "Sales > Braintree Virtual Terminal patch. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>BUNDLE-2670 Braintree Virtual Terminal patch</em>

**2.3.3**

Catalog pagination issue on Elasticsearch 6.x patch. No results after page 1. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>Catalog pagination issue on Elasticsearch 6.x patch</em>

**2.2.5**

Performance optimization for retrieving product attributes patch. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>MAGETWO-93083</em>

**2.2.4**

Magento multi-store installations don't use store view-specific values from the store configuration settings. Instead uses default regardless of settings. Located in [Magento Patch Downloads](https://magento.com/tech-resources/download) under <em>MAGETWO-92926</em>

**2.1+**

Patch to fix magento/framework/Stdlib/Cookie/PhpCookieManager.php and raise MAX_NUM_COOKIES from 50 to 300. Located in the [MageMojo Patch Repo](https://github.com/magemojo/m2-patches) under <em>Magento2-Framework-Stdlib-Cookie-PhpCookieManager</em>
---
# Stratus - Sending Bulk Emails
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/mass-mailing-at-magemojo/
Description: While Magento can support the sending of an email to customers, Webscale STRATUS recommends that a third-party service be used for newsletters and marketing communication. Bulk mails may result in IP blacklisting by an ISP, which is outside the control or influence of Webscale. Intentional spam is a violation of our Acceptable Use Policy and will result in immediate termination of your account.





> *Transactional emails*, such as invoices, shipping updates, etc. are not usually problematic since these do not require marketing permission from customers.

Once an IP is *blacklisted* by ISPs, it is very difficult to overcome the listing. IP blacklisting is outside of the control or influence of Webscale STRATUS.

> Intentional spam is a violation of our [Acceptable Use Policy](https://www.webscale.com/acceptable-use-policy/) and will result in immediate termination of your account.
---
# Stratus - Changing Account Ownership
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/recover-a-magemojo-com-account-or-server/
Description: In the event that an account has been managed by a third party and is not accessible by the store owner, Webscale STRATUS can help regain the account.





Especially when a new Magento store has been set up and configured by an outside agency or contractor, the store owner may find that they cannot access the Webscale STRATUS account. This can be problematic when the relationship with the provider has concluded without a proper transfer of access.

> Webscale can only assist with regaining an account for which the store owner is actually the direct payor of Webscale STRAUS fee. For accounts that are resold through partners, the store owner must work with the partner for access issues.

If a store owner cannot access the account for which they are paying, they should first contact the outside provider for help in transferring account control.

## Switching an Account

First, for the **current account owner**:

1. *Log into* the [Webscale STRATUS account](https://magemojo.com/magento/customer/account/login/ "MageMojo Account Login").
2. *Go to* **Profile** in the sidebar menu.
	* **Email Address** — *Enter* the email address of the *new owner*.
	* **Current Password** — *Enter* the current owner password for change validation.
3. *Click* **SAVE**.

The current account owner should then email the new owner with the current account password. The new owner can then *log into* Webscale STRATUS with their email address and the account password.

> **NOTE:** the new owner should change the account password and update name and other account information as necessary.

## Regaining an Account

In the event that the current owner cannot be contacted or is unresponsive to requests for account ownership transfer, the new owner should [contact our support](/docs/getting-started/support/) and provide Webscale STRATUS with:

* The last four digits of the credit card used for current payment of MageMojo fees.
* The billing address associated with the payment method.

> Webscale STRATUS may require additional information to validation ownership since transferral of hosting ownership is a critical security issue.
---
# Stratus Logs
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/stratus-log-locations/
Description: Log files generated by a STRATUS environment are located in the `/log` directory.





Within this directory, there are subdirectories for the following log types:

* exim: outgoing transactional mail logs
* php-fpm: php access. error and slow logs
* mysql: mysql errors logs and slow query logs
* sshd: ssh logs. Note these logs are not always complete. Snoopy logs below are reliable.
* snoopy: Logs showing CLI history on the system along with the time stamp. Stored location is off-server.

Access and error logs for Nginx are located in the root of the `/log` directory.

Logs are rotated daily and retained for up to one (1) year.
---
# Using MTR
URL: https://docs.webscale.com/docs/reference/stratus/hosting-support/using-winmtr/
Description: Webscale STRATUS Support may request that *WinMTR* be used to diagnose network issues.



 Occasionally, network problems may be local or regional and, therefore, affect the accessibility of the store by developers or store owners.

Use of MTR can confirm that any access issues are or are not a local problem.

## Windows

  1. *Download* [WinMTR](https://sourceforge.net/projects/winmtr/ "WinMTR Download").
  2. *Extract* the archive and *run* the included `WinMTR.exe`.

  {{< figure src="/images/stratus/img/articles/mtr1.png" alt="mtr-63" >}}

  3. *Enter* the Webscale STRATUS hostname in **Host** (e.g. `www.magemojo.com`).
  4. *Click* **Start**
  5. After the tests run for a few moments, *click* **Stop**.

  {{< figure src="/images/stratus/img/articles/mtr2.png" alt="mtr-55" >}}

  6. *Click* **Export Text**
  7. *Save* the text file.
  8. *Send* the exported text file to [Webscale Support](/docs/getting-started/support/) as an attachment.

## MacOS and Linux

  1. *Open* a shell on your system (e.g. *Terminal* for MacOS).
  2. *Run* `mtr example.hostname.com`, substituting the Webscale STRATUS account hostname for "example.hostname.com".
  3. After the test runs for a few momements, *exit* the command.

  {{< figure src="/images/stratus/img/articles/mtr3.png" alt="mtr-37" >}}

  4. *Copy* the results to Webscale STRATUS Support.
---
# Storage
URL: https://docs.webscale.com/docs/reference/stratus/storage/
Description: Storage

---
# STRATUS Architecture Legacy Limits
URL: https://docs.webscale.com/docs/reference/stratus/storage/limits-legacy/
Description: Webscale STRATUS has three types of environments - Auto-scaling environments, Development environments, and Resource Base Pricing environments.


# Limits for Discontinued plans

Autoscaling environments are the default and recommended production environments for STRATUS.  The autoscaling environments will scale out your website frontend horizontally and automatically in response to surges in traffic.

Autoscaling environments have two types - *Single tenant* and *Multi tenant*.

*Multi tenant* - Starter, Lite, Plus and Select, have all services running across the shared STRATUS platform. The limits in the services are aggregated as a total.

*Single tenant* - Elite, and Custom, have a dedicated ec2 instance for their services except PHP.  PHP is scaled across the shared STRATUS platform.  The limits in the services are not aggregated as a total. The service limits are allowed to use the max resources in the dedicated ec2 instance.

*CPU = Logical Cores, RAM = GB*

## Autoscaling: Multi tenant

|                  |Starter|Pro |Pro Plus|Pro Elite|Growth|
|------------------|-------|----|--------|---------|------|
|Mysql CPU         |4      |8   |8       |8        |10    |
|Mysql RAM         |4      |8   |12      |16       |32    |
|PHP CPU           |Auto   |Auto|Auto    |Auto     |Auto  |
|PHP RAM           |Auto   |Auto|Auto    |Auto     |Auto  |
|Varnish CPU       |1      |1   |1       |1        |1     |
|Varnish RAM       |2      |4   |4       |6        |8     |
|Nginx CPU         |1      |1   |1       |1        |1     |
|Nginx RAM         |1      |2   |2       |3        |4     |
|Cron CPU          |1      |1   |1       |1        |1     |
|Cron RAM          |2      |4   |4       |6        |8     |
|SSH CPU           |1      |1   |1       |1        |1     |
|SSH RAM           |2      |4   |4       |6        |8     |
|Redis Cache CPU   |1      |1   |1       |1        |1     |
|Redis Cache RAM   |1      |2   |4       |4        |4     |
|Redis Sessions CPU|1      |1   |1       |1        |1     |
|Redis Sessions RAM|1      |2   |2       |3        |4     |
|Redis FPC CPU     |1      |1   |1       |1        |1     |
|Redis FPC RAM     |2      |4   |4       |4        |6     |
|ElasticSearch CPU |1      |2   |2       |2        |4     |
|ElasticSearch RAM |2      |4   |4       |6        |8     |
|Memcache CPU      |1      |1   |1       |1        |1     |
|Memcache RAM      |1      |2   |2       |3        |4     |
|Sphinx CPU        |1      |2   |2       |2        |2     |
|Sphinx RAM        |2      |4   |4       |6        |8     |
|RabbitMQ CPU      |1      |1   |1       |1        |1     |
|RabbitMQ RAM      |1      |1   |1       |1        |1     |
|NodeJS CPU        |1      |1   |1       |1        |1     |
|NodeJS RAM        |1      |1   |1       |1        |1     |
|API Rate limit    |2/s    |25/s|25/s    |30/s     |35/s  |

## Autoscaling: Single tenant

|                  |Scale|Enterprise|
|------------------|-----|----------|
|Mysql CPU         |12   |24        |
|Mysql RAM         |86   |180       |
|PHP CPU           |Auto |Auto      |
|PHP RAM           |Auto |Auto      |
|Varnish CPU       |12   |24        |
|Varnish RAM       |12   |12        |
|Nginx CPU         |12   |24        |
|Nginx RAM         |12   |12        |
|Cron CPU          |12   |24        |
|Cron RAM          |12   |12        |
|SSH CPU           |12   |24        |
|SSH RAM           |12   |12        |
|Redis Cache CPU   |12   |24        |
|Redis Cache RAM   |12   |12        |
|Redis Sessions CPU|12   |24        |
|Redis Sessions RAM|12   |12        |
|Redis FPC CPU     |12   |24        |
|Redis FPC RAM     |12   |12        |
|ElasticSearch CPU |12   |24        |
|ElasticSearch RAM |12   |20        |
|Memcache CPU      |12   |24        |
|Memcache RAM      |12   |12        |
|Sphinx CPU        |12   |24        |
|Sphinx RAM        |12   |12        |
|RabbitMQ CPU      |1    |1         |
|RabbitMQ RAM      |1    |1         |
|NodeJS CPU        |1    |1         |
|NodeJS RAM        |1    |1         |
|API Rate limit    |50/s |75/s      |


## Development environments

Development environments are used for creating development copies.  All Development environments are multi tenant. The limits in these services are aggregated as a total.

*CPU = Logical Cores, RAM = GB*

|                  |Dev |
|------------------|-----------|
|Varnish CPU       |1          |
|Varnish RAM       |2          |
|Nginx CPU         |1          |
|Nginx RAM         |1          |
|Mysql CPU         |4          |
|Mysql RAM	       |4          |
|PHP CPU           |8          |
|PHP RAM           |6          |
|Cron CPU          |1          |
|Cron RAM          |2          |
|SSH CPU           |1          |
|SSH RAM           |2          |
|Redis Cache CPU   |1          |
|Redis Cache RAM   |2          |
|Redis Sessions CPU|1          |
|Redis Sessions RAM|1          |
|Redis FPC CPU     |1          |
|Redis FPC RAM     |1          |
|ElasticSearch CPU |1          |
|ElasticSearch RAM |1          |
|Memcache CPU      |1          |
|Memcache RAM      |1          |
|Sphinx CPU        |1          |
|Sphinx RAM        |2          |
|RabbitMQ CPU      |1          |
|RabbitMQ RAM      |1          |
|NodeJS CPU        |1          |
|NodeJS RAM        |1          |

## Resource Based Pricing environments

<font color="red">Discontinued:</font> Resource Based Pricing environments are not recommended for most customers.  These should only be used by customers running highly optimized code or for other types of software that are not Magento.  They are not autoscaling plans.  The limits in the services are aggregated as a total.

*CPU = Logical Cores, RAM = GB*

|                  |RBP-4|RBP-16|
|------------------|-----|------|
|Varnish CPU       |1    |1     |
|Varnish RAM       |2    |4     |
|Nginx CPU         |1    |1     |
|Nginx RAM         |2    |4     |
|Mysql CPU         |5    |11    |
|PHP CPU           |5    |11    |
|PHP RAM           |18   |30    |
|Mysql RAM         |18   |30    |
|Cron CPU          |2    |2     |
|Cron RAM          |4    |4     |
|SSH CPU           |1    |1     |
|SSH RAM           |2    |4     |
|Redis Cache CPU   |1    |1     |
|Redis Cache RAM   |2    |4     |
|Redis Sessions CPU|1    |1     |
|Redis Sessions RAM|2    |4     |
|Redis FPC CPU     |1    |1     |
|Redis FPC RAM     |2    |4     |
|ElasticSearch CPU |1    |1     |
|ElasticSearch RAM |2    |4     |
|Memcache CPU      |1    |1     |
|Memcache RAM      |2    |4     |
|Sphinx CPU        |1    |1     |
|Sphinx RAM        |2    |4     |
|RabbitMQ CPU      |1    |1     |
|RabbitMQ RAM      |1    |1     |
|NodeJS CPU        |1    |1     |
|NodeJS RAM        |1    |1     |
---
# Stratus Guides - Install IonCube Loader
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/install-ioncube-loader-on-stratus/
Description: Currently, ionCube Loader for PHP 8 is not installed as default on the Stratus Platform due to performance reasons. The following steps can be applied to install it manually for PHP 8.1


  Note: ionCube Loader for PHP 8 installation at the server with Webscale Stratus had not been tested, and we cannot guarantee its stability.

To Install IonCube Loader in your Stratus environment, follow these steps:

1. ```cd /srv/```

2. ```wget https://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz```

3. ```tar -xvf ioncube_loaders_lin_x86-64.tar.gz```

4. ```
      mkdir php_conf
      cp -a /usr/local/etc/php/conf.d/* php_conf
      cd php_conf/
      rm zzz_custom.ini
      ln -s /usr/local/etc/php/conf.d/zzz_custom.ini ./
      cp /usr/local/etc/php/php.ini ./
      ```

5. While still in php_conf dir, create a file named _00_ioncube.ini_ with the following content:

```echo "zend_extension=/srv/ioncube/ioncube_loader_lin_8.1.so" > 00_ioncube.ini```

6. Edit /srv/.bash_profile file and add the following:

```
export PHP_INI_SCAN_DIR=/srv/php_conf
```

7. Test. Redeploy the environment, and you should be getting, by default, ionCube loader loaded.

```
www@somewhere:~$ php -v | grep -i ioncube
    with the ionCube PHP Loader v12.0.2, Copyright (c) 2002-2022, by ionCube Ltd.
```

8. <a href="/getting-started/support/">Open up a ticket</a> with Webscale Stratus support, so we can add the following environment variables for PHP-FPM.

```
PHP_INI_SCAN_DIR = /srv/php_conf
```

# Troubleshooting

* In order to run a cron with ioncube, you will need to configure it as follows so the cron container can locate it:

```
-p 1; source /srv/.bashrc; COMMAND-TO-BE-EXECUTED
```

* Note that currently NewRelic will not work when IonCube is enabled.
---
# Stratus Guides - Using Varnish
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/enable-varnish-on-stratus/
Description: When your store is live on Mojo STRATUS, you will want to use Varnish for the Magento 2 FPC. Varnish improves page load time and concurrency to a staggering degree.


## Enable Varnish for Magento 2

To enable Varnish on your store, follow these steps:

  1. Log into your Magento 2 admin panel.
  2. Connect to your store admin panel and go to Stores → Settings → Configuration → Advanced → System → Full Page Cache
  3. In the FPC section, configure it as in the screenshot below
  ![varnish](/images/stratus/img/articles/varnish-magento.png)
  4. Save the configuration
  5. Now log into your STRATUS Store Panel
  6. Go to the **Varnish** area from the left-hand navigation menu, click to expand and select the **Info** section.
  7. Click **Enable** to start the Varnish service. (Note: this will redeploy all services)
  8. Varnish is now enabled!

## Enable Varnish with Turpentine

If you are using Magento 1 and Turpentine, the configuration for Turpentine should use:

  * **127.0.0.1** for the backend host

Then

  1. Log into your STRATUS Store Panel
  2. Go to the **Varnish** area from the left-hand navigation menu, click to expand and select the **Info **section.
  3. Click **Enable** to start the Varnish service.
  4. Varnish is now enabled!

## Using a Custom VCL
You can add a custom VCL under **Varnish->VCL**. It will cause a redeploy of services once applied. You can view the default VCL used under **Varnish->Info**.
Please note that you must use the following **acl purge block** for purge to work correctly.

```
acl purge {
    "127.0.0.1";
    "192.168.0.0/16";
    "10.0.0.0/8";
}
```


## Purging Varnish On STRATUS

Curl works if you are using SSH, the difference is the Varnish hostname is **varnish**

```curl -X 'PURGE' -H'X-Magento-Tags-Pattern: .*' varnish```

Varnish also clears with the STRATUS [cache.varnish.clear](/docs/reference/stratus/guides/webscale-stratus/stratus-cli/) or [cache.all.clear](/docs/reference/stratus/guides/webscale-stratus/stratus-cli/) commands via SSH.

```/usr/share/stratus/cli cache.varnish.clear```

```/usr/share/stratus/cli cache.all.clear```

Magento 2 users should set their http-cache-host accordingly:

```php bin/magento setup:config:set --http-cache-hosts=varnish```
---
# Stratus Guides - Install Sourceguardian
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/install-sourceguardian-on-stratus/
Description: For performance reasons, the SourceGuardian Loader for PHP 8 is not installed as default on the Stratus Platform. The following steps can be applied to install it manually for PHP 8.1


# Installation

To Install SourceGuardian Loader in your Stratus environment, follow these steps:

1. ```cd /srv/```

2. Create a folder: ```mkdir sourceguardian```

3. Get linux x64 loader using the following command:
```curl 'https://www.sourceguardian.com/loaders/download/loaders.linux-x86_64.tar.gz' -H 'authority: www.sourceguardian.com' -H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' -H 'accept-language: en-GB,en-US;q=0.9,en;q=0.8,hr;q=0.7' -H 'cache-control: no-cache' -H 'cookie: RGTR=40811663063942; SiteSession1=1csd7upu9i6s3jvuss3v3ueuf7' -H 'pragma: no-cache' -H 'referer: https://www.google.com/'   -H 'sec-ch-ua: ""' -H 'sec-ch-ua-mobile: ?0' -H 'sec-ch-ua-platform: ""' -H 'sec-fetch-dest: document' -H 'sec-fetch-mode: navigate' -H 'sec-fetch-site: cross-site' -H 'sec-fetch-user: ?1' -H 'upgrade-insecure-requests: 1' -H 'user-agent: Chrome' --output /srv/sourceguardian/loaders.linux-x86_64.tar.gz```

4. Cd into a folder, extract Sourceguardian loaders and then go back to the /srv/ directory:
```cd sourceguardian;tar -xvf loaders.linux-x86_64.tar.gz;cd ..```

5. ```
      mkdir php_conf
      cp -a /usr/local/etc/php/conf.d/* php_conf
      cd php_conf/
      rm zzz_custom.ini
      ln -s /usr/local/etc/php/conf.d/zzz_custom.ini ./
      cp /usr/local/etc/php/php.ini ./
      ```

6. While still in php_conf dir, create a file named _00_sourceguardian.ini_ with the sourceguardian extension:

```echo "zend_extension=/srv/sourceguardian/ixed.8.1.lin" > 00_sourceguardian.ini```

7. Edit /srv/.bash_profile file and add the following:

```
export PHP_INI_SCAN_DIR=/srv/php_conf
```

8. Test. Redeploy the environment, and you should be getting, by default, SourceGuardian loader loaded.

```
www@somewhere:~$ php -v | grep -i Source
    with SourceGuardian v13.0.3, Copyright (c) 2000-2022, by SourceGuardian Ltd.
```

9. <a href="/getting-started/support/">Open up a ticket</a> with Webscale Stratus support, so we can add the following environment variables for PHP-FPM.

```
PHP_INI_SCAN_DIR = /srv/php_conf
```

# Troubleshooting

* In order to run a cron with SourceGuardian, you will need to configure it as follows so the cron container can locate it:

```
-p 1; source /srv/.bash_profile; COMMAND-TO-BE-EXECUTED
```

* Note that currently NewRelic will not work when SourceGuardian is enabled.
---
# Stratus Guides - Using SupervisorD
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/using-supervisord/
Description: Instructions on how to split consumers to the SupervisorD service on STRATUS.

<a href = "http://supervisord.org/introduction.html">Supervisor</a> is a client/server system that allows its users to control a number of processes like Magento consumers.   Note: this is only possible on PHP 7.4 and above.

# Installation
Versions of Python available in your environment will depend on which <a href="https://docs.webscale.com/reference/stratus/control-panels/php-panel/version/">PHP version</a> you are using. You can see which version is currently running on your system by running ```python --version``` Note that installing SupervisorD is only possible on PHP 7.4 and above.

## Python 2.7 install
Installing SupervisorD for Python 2.7.x

1. ```pip install --target=/srv/.local/lib/python2.7/site-packages/ setuptools supervisor```

2. Generate the initial config file with the following commands:

```
mkdir -p /srv/supervisord
cd /srv/supervisord;
wget -c https://raw.githubusercontent.com/magemojo/m2-patches/main/supervisord.conf
```

3. Binary files can be found under /srv/.local/lib/python2.7/site-packages/bin/ directory, so we can create a symlink and test using this command:

```
cd ~/.local; ln -s /srv/.local/lib/python2.7/site-packages/bin/ bin;
/srv/.local/bin/supervisord -c /srv/supervisord/supervisord.conf
```

4. Create the start.sh file if needed. If this environment is using PWA, you will not need to create start.sh since it already exists, so you may skip to step 5. Otherwise create the file as follows:

```
mkdir -p /srv/pwa
cd /srv/pwa
touch start.sh ; chmod a+rwx start.sh
```

5. Edit start.sh file and update/add the sequence to start supervisord daemon.

```
pip install setuptools supervisor
/srv/.local/bin/supervisord -c /srv/supervisord/supervisord.conf
```

<b>Important!</b> If you are running a PWA application in that container, then please update /srv/supervisord/supervisord.conf file line `nodaemon=true` to `nodaemon=false`

## Python 3.7 install
Installing SupervisorD for Python 3.7.x

1. ```pip3 install --target=/srv/.local/lib/python3.7/site-packages/ setuptools supervisor```

2. Generate the initial config file with the following commands:

```
mkdir -p /srv/supervisord
cd /srv/supervisord;
wget -c https://raw.githubusercontent.com/magemojo/m2-patches/main/supervisord.conf
```
3. Binary files can be found under /srv/.local/lib/python3.7/site-packages/bin/ directory, so we can create a symlink and test using this command:

```
cd ~/.local; ln -s /srv/.local/lib/python3.7/site-packages/bin/ bin;
/srv/.local/bin/supervisord -c /srv/supervisord/supervisord.conf
```

4. Create the start.sh file if needed. If this environment is using PWA, you will not need to create start.sh since it already exists, so you may skip to step 5. Otherwise create the file as follows:

```
mkdir -p /srv/pwa
cd /srv/pwa
touch start.sh ; chmod a+rwx start.sh
```

5. Edit start.sh file and update/add the sequence to start supervisord daemon.

```
pip3 install setuptools supervisor
/srv/.local/bin/supervisord -c /srv/supervisord/supervisord.conf
```

<b>Important!</b> If you are running a PWA application in that container, then please update /srv/supervisord/supervisord.conf file line `nodaemon=true` to `nodaemon=false`

# Launching SupervisorD in the NodeJS container

1. Go to the <a href="https://docs.webscale.com/reference/stratus/control-panels/nodejs-panel/info/">Stratus panel</a> and start the NodeJS container.

2. Please <a href="https://docs.webscale.com/getting-started/support/">place a ticket with support</a> and request that Tier2 _"Create a custom PHP Container to run consumers with SupervisorD"_ and reference this article. When that portion is completed, you may return here to complate the configuration below titled _"Configure consumers to run in supervisord"_

# Configure consumers to run in supervisord

1. Login back to the SSH container and execute the following:

```
mkdir -p /srv/supervisord/conf.d
cd /srv/supervisord
echo "LD_LIBRARY_PATH=/srv/php/lib /srv/php/bin/php bin/magento queue:consumers:start async.operations.all" > async.sh; chmod a+rwx async.sh
cd /srv/supervisord/conf.d
cat <<EOT >> /srv/supervisord/conf.d/async.conf
[program:async-queue]
process_name=%(program_name)s
directory=/srv/public_html
command=bash /srv/supervisord/async.sh
autostart=true
autorestart=true
user=www
numprocs=1
redirect_stderr=true
stdout_logfile=/srv/supervisord/%(program_name)s.log
EOT
```

** Note: Adjust directory= with where Magento 2 docroot is. Example above is for async.operations.all, create one by one for each Consumer that you wish to offload from Cron to Supervisor mechanism.

2. Start/Restart the NodeJS container; If running `ps aux |  grep start` and `kill start.sh` process running, so it restarts with the new setting.

3. To test if supervisor is active:

```
/srv/.local/bin/supervisorctl status
```

Correct output:

```
async-queue                      RUNNING   pid 93608, uptime 0:00:15
```

4. In the last step, we have to disable Consumers running as Cron tasks in env.php

```
'cron_consumers_runner' => [
        'cron_run' => false,
        'max_messages' => 0,
        'consumers' => [
        ]
    ],
```

The empty place will consider they all will be running from something else and that is Supervisor.

# POISON PILL
To keep Consumers in order and prevent failures or memory leaking (known problem), here is instruction on creating an additional Supervisord program called Poison Pill which will restart all consumers at 7200 seconds intervals.

1. Create a file named poison.sh within /srv/supervisord directory with the following contents:


```
#!/bin/bash
while :
do
    sleep 7200
    ps aux | grep consumer | awk {'print $2'} | xargs kill -s 9
done
```

2. Run the following:

```
cat <<EOT >> /srv/supervisord/conf.d/poison.conf
[program:poison-pill]
process_name=%(program_name)s
directory=/srv/public_html
command=bash /srv/supervisord/poison.sh
autostart=true
autorestart=true
user=www
numprocs=1
redirect_stderr=true
stdout_logfile=/srv/supervisord/%(program_name)s.log
EOT
```

Logs can be found in the /srv/supervisord folder
---
# Stratus Guides - Install MailHog
URL: https://docs.webscale.com/docs/reference/stratus/guides/webscale-stratus/using-mailhog/
Description: <a href="https://github.com/mailhog/MailHog">MailHog</a> is a popular tool for testing Email templates on any platform.



1. In the SSH container, navigate to ~/bin directory and execute the following command:

```
wget -c https://go.dev/dl/go1.19.5.linux-amd64.tar.gz
```

2. Extract archive:

```
tar -xvf go1.19.5.linux-amd64.tar.gz
```

3. Export PATH:

```
export PATH=$PATH:/srv/bin/go/bin
```

4. Navigate to /srv/pwa directory and execute:

```
go install github.com/mailhog/MailHog@latest
```

5. Adjust start.sh file in the /srv/pwa directory or create it fresh with the following details:

```
#!/bin/bash
export PATH=$PATH:/srv/bin/go/bin
/srv/go/bin/MailHog -ui-web-path /mailhog -smtp-bind-addr 0.0.0.0:10000
```

  Note: If you are already running some NodeJS application, adjust the export path accordingly as an add-on to the current NVM settings.

6. Test ./start.sh before starting up the Node container from within the Stratus panel. This is how it should look if MailHog is started properly:

{{< figure src ="/images/stratus/img/mailhog.png" >}}

7. Following <a href="https://docs.webscale.com/reference/stratus/control-panels/nodejs-panel/info/">NodeJs</a> guidelines navigate to your Stratus panel and start the container. If everything remains in the “Running” state, the MailHog container is started successfully and fully functional.


8. Next, we need to download and install `mhsendmail` tool and adjust the PHP configuration to use it when sending emails.

```
cd ~/bin
wget https://github.com/mailhog/mhsendmail/releases/download/v0.2.0/mhsendmail_linux_amd64
chmod +x mhsendmail_linux_amd64
mv mhsendmail_linux_amd64 mhsendmail
```

9. Add the following alias to the ~/.bashrc file:

```
alias mhsendmail='/srv/bin/mhsendmail'
export PATH=$PATH:/srv/bin/go/bin
```

10. Create the /srv/smwrap.sh file:

```
/srv/bin/mhsendmail --smtp-addr=nodejs:10000
```

11. Navigate to `Stratus panel → PHP → Option` section and add the following:

```
sendmail_path=/srv/smwrap.sh
```

12. The last step is to add the following into the `Nginx → Includes` section area from within the Stratus panel:

```
location /mailhog {
proxy_pass http://0.0.0.0:8025;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-SSL-offloaded $ssl_offloaded;
proxy_buffer_size          128k;
proxy_buffers              4 256k;
proxy_busy_buffers_size    256k;
}
```

When you start the container and add the Nginx rule, the UI should look as follows:

{{< figure src="/images/stratus/img/mailhogss.png" >}}
---
# Stratus - PWA Configuration
URL: https://docs.webscale.com/docs/reference/stratus/guides/pwa-configuration/
Description: Progressive Web Apps (PWA) are built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and stability while reaching anyone, anywhere, on any device with a single codebase.


Currently, Stratus supports PWA Studios and Vue Storefront. Other popular PWA frameworks are available such as Simicart, ScandiPWA, Tigren, BSSCommerce, CedCommerce, and MageDelight.
To read more about the benefits of PWA, please read [PWA and Headless Commerce](/docs/reference/stratus/guides/optimizations/pwa-and-headless-commerce/)
## PWA Setup

Stratus supports hosting your frontend through [PWA Studio](https://magento.github.io/pwa-studio/venia-pwa-concept/setup/)

Before enabling PWA services via your Stratus panel, you should prepare your PWA installation. This requires knowledge of NVM, NodeJS and PWA Studio.  Follow the steps below to install and configure the sample PWA Studio frontend provied by Adobe.

1. Log into your Stratus instance via SSH
2. cd to your Magento root directory. Example `cd /srv/public_html`
3. Retrieve the PWA Metapackage for Magento Open Source Extensions: `git clone https://github.com/magento/magento2-pwa.git ext/magento/magento2-pwa;`
4. `composer config minimum-stability dev;`
5. `composer config repositories.ext path "./ext///*";`
6. `composer require magento/pwa;`
7. `php bin/magento module:status | grep Pwa | xargs php bin/magento module:enable`
8. `php bin/magento module:status | grep Aux | xargs php bin/magento module:enable`
9. `php bin/magento setup:upgrade`
10. `php bin/magento setup:di:compile`
11. `php bin/magento setup:static-content:deploy`
12. Export your stores UUID as an environment variable `export UUID=(your UUID here)`
13. For Magento versions higher than 2.4.3:
Run `/usr/share/stratus/pwa-example-venia.sh` PWA Studio and the local NVM install will be automatically copied into /srv/pwa for you.
For Magento 2.4.3 version or older:
`cp /usr/share/stratus/pwa-example-venia.sh /srv/pwa-example-venia.sh`
Edit the following section of /srv/pwa-example-venia.sh to utilize the [correct version](https://developer.adobe.com/commerce/pwa-studio/integrations/adobe-commerce/version-compatibility/) Run it and PWA Studio with the local NVM install will be automatically copied into /srv/pwa for you.
```
cd /srv/pwa
git clone --branch v12.1.0 https://github.com/magento/pwa-studio.git; cd /srv/pwa/pwa-studio; cp -avr .* /srv/pwa; cd /srv/pwa; rm -r -f pwa-studio;
```
13. Open your Stratus Control Panel and enable NodeJS in the NodeJS -> Info section.  Click the *Enable* button.  Turning on NodeJS will redeploy all store services and cause several minutes of downtime. *Do not enable NodeJS if you have not added the PWA app into /srv/pwa*
14. In the same NodeJS section of the Stratus Control Panel, open the PWA section.  Here you will see all the domains applied to your instance.  You can choose to set them to PHP or NodeJS.  Selecting either changes the fastcgi backend proxy in the Nginx configuration. If a domain is set to PHP, it will forward to PHP-FPM.  If NodeJS is selected, the requests will be routed to NodeJS, instead.  This way you can host normal Magento 2 views alongside separate PWA applications for your store. Select and configure each domain as needed for your application.
15. Click *Update* to confirm the configuration
16. Visit one of your domains set to NodeJS, you should see your PWA frontend loading instead of the Magento 2 default for your store.

For development, you can use this start.sh file within /srv/pwa directory with following lines:
```
#!/bin/bash
export NVM_DIR=/srv/pwa/nvm
. "$NVM_DIR/nvm.sh"
cd /srv/pwa
yarn run stage:venia

```
NVM is localized with PWA on Stratus, as well as in /srv/.nvm.  Keeping a separate install allows you to maintain separate Node versions for different applications between Magento compilation and PWA.

Additional commands you can run within the SSH container for testing via yarn:

* *yarn run watch:venia*
Starts the Venia storefront development environment.

* *yarn run watch:all*
Runs the full PWA Studio developer experience, which include Venia hot-reloading and concurrent Buildpack/Peregrine rebuilds.

* *yarn run build && yarn run stage:venia*
Generates build artifacts and runs the staging environment, which uses more compressed assets and more closely reflects production.

## Vue Storefront Setup

Stratus supports hosting your frontend through [Vue Storefront](https://github.com/vuestorefront/vue-storefront)

Vue Storefront is a headless and backend-agnostic eCommerce Progressive Web App written in Vue. The fact that it uses headless architecture allows Vue Storefront to be connected with any eCommerce platform, so it can be a frontend PWA for Magento, Shopify, BigCommerce, WooCommerce, etc.

To host VueStorefront (Demo) on MageMojo Stratus:

* Login to your SSH container and check the following:
```
node -v
```
This will output the NodeJS version used. You may need to adjust this for compatibility with the version of Vue Storefront chosen.
For the purpose of this article, we are using NodeJS 12.22.7 which requires the following commands as described in [Node.js Node Version Manager](/docs/reference/stratus/guides/general/node-js-nvm-manager/).
```
nvm install 12.22.7
nvm use 12.22.7
npm install yarn -g
```
At the time of this article, the latest Vue Storefront version was 1.12.2

* Within the same session, run the following:
```
cd /srv/;
git clone --single-branch --branch master https://github.com/vuestorefront/vue-storefront-1.git pwa
```
If you would like a different version instead, replace _master_ with the [appropriate branch name](https://github.com/vuestorefront/vue-storefront-1).

* Navigate to /srv/pwa, and then execute:
```
yarn
```

* Since the NodeJS container runs on port 10000 by default, we will need to run the following command before going further. Note: See Shopify section below if this is not for Magento
```
sed -i 's/3000/10000/g' ./config/default.json
sed -i 's/3000/10000/g' ./config/test.json
```

* Next, we can run the installer:
```
yarn installler
```

{{< figure src="/images/stratus/img/articles/vue1.png" >}}
If you answer Yes, you will have a remote backend at https://demo.vuestorefront.io. Otherwise, you will need to install vue-storefront-api.
{{< figure src="/images/stratus/img/articles/vue2.png" >}}

* Configuration is ready, and we can now create the start.sh file under the /srv/pwa directory.

Navigate back to the /srv/pwa folder. For development, you can use this start.sh file within /srv/pwa directory with the following lines:

```
#!/bin/bash
set -e
cd /srv/pwa &&
export NVM_DIR=/srv/pwa/nvm
mkdir -p $NVM_DIR

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
. "$NVM_DIR/nvm.sh"
nvm install 12.22.7
nvm use 12.22.7
npm install yarn -g
yarn install || exit $?
cd /srv/pwa; yarn dev
```

Make you adjust for your version of node used in the first step.

* Once you have saved the file, make it executable:
```
chmod u+x start.sh
```

* The next step is to Open your Stratus Control Panel and [enable NodeJS](/docs/reference/stratus/control-panels/nodejs-panel/info/). Turning on NodeJS will redeploy all store services and cause several minutes of downtime.

* Once the environment is back online, you may [select which domain will be using NodeJS](/docs/reference/stratus/control-panels/nodejs-panel/pwa/).

> **NOTE**: For the shopify headless version, the process is similar to above except for the port change needs to be done in /srv/pwa/package.json as follows.
```
package.json
    "scripts": {
      "dev": "nuxt --port 10000",
      "build": "nuxt build -m",
      "build:analyze": "nuxt build -a -m",
      "start": "nuxt start --port 10000",
      "generate": "nuxt generate",
    "test": "jest"
```

## Troubleshooting

* NodeJS not starting? Is start.sh located in /srv/pwa/ ? Does start.sh have executable permissions? (chmod u+x start.sh)
* Errors about missing environment variables? try adding these to start.sh like so:
```
export MAGENTO_BACKEND_URL=https://mymagentourl.com/
export CHECKOUT_BRAINTREE_TOKEN=sandbox_11111110000001111111
```
> **NOTE**: This is just an example. These values should be replaced with the actual Magento backend URL and sandbox token
---
# Stratus Panel — SSH > Whitelist
URL: https://docs.webscale.com/docs/reference/stratus/storage/whitelist/
Description: Each SSH user created can only be allowed access if their IP is whitelisted.


## Add a Whitelist

To assign one or more allowed IPs to a SSH user:

{{< figure src="/images/stratus/img/articles/ssh-whitelist-1.png" alt="ssh whitelist-1" >}}

  1. *Go to* **SSH > Users** in the STRATUS sidebar menu.
  2. Scroll down to the bottom of the screen under the "Whitelisted IPs" heading.
	* **IP Address, Subnet Or Valid Hosts.** — *Enter* the IP address the user will be allowed to access the STRATUS environment from then click **ADD IP** . A subnet range or multiple IP addresses may be included (comma-separated). To quickly determine your IP address (if you wish to allow the computer you are using), *click* **Get My IP Address**. Your IP address will be automatically entered.
	* **Label** — enter a name for the particular allowance created, such as "Office" or "Home."
  3. *Click* **UPDATE** to save the new entry.

> A single user can be assigned to multiple allowed Whitelist entries. However, only one user can be assigned to any given Whitelist entry. With the use of multiple IPs in an entry, labels may be created by user name rather than by location (e.g. Bill, Hans, Maria).

## Edit a Whitelist

To **edit** an existing whitelist, *click* on the entry in the list. *Update* the entry and *click* **UPDATE** to save the changes.

## Delete a Whitelist

To **delete** an existing whitelist, *click* on the entry in the list. *Click* **DELETE** to delete the whitelist record.
---
# Stratus - Status Page
URL: https://docs.webscale.com/docs/reference/stratus/health-checks/status-page/
Description: Do you have a Status page for maintenance and outages? Yes, we do.


This can be found at <a class="external-link" href="http://status.magemojo.com/" rel="nofollow">http://status.magemojo.com/</a>
---
# Password Guidance
URL: https://docs.webscale.com/docs/how-tos/security/password-guidance/
Description: Password Guidance



The Webscale Control Panel requires that you change your password every 90 days. A password must be at least 8 characters, and must contain at least one digit, one uppercase character, and one lowercase character. Webscale recommends using generated passwords and storing them in a secure password manager to avoid easy-to-guess passwords. Ensure that you do not use your Control Panel password for any other services.

Webscale recommends using [Multi-Factor Authentication](/docs/how-tos/security/mfa/) to provide an additional layer of protection to your access.

## Was my account compromised?

If you think your access to the Control Panel has been compromised, change your password and contact [Webscale Support](/docs/getting-started/support/) immediately.

Webscale may disable access for users whose access appears to be compromised. If this occurs, you will need to contact Webscale Support to get your access reinstated.

## Further reading
- [How to Create Roles and Invite Users](/docs/how-tos/general/user-roles/)
- [How to Use Webscale Secure Access](/docs/how-tos/security/secure-access/)
- [How to Configure Multi-Factor Authentication](/docs/how-tos/security/mfa/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
---
# Security Monitoring
URL: https://docs.webscale.com/docs/how-tos/security/security-monitoring/
Description: How to configure security monitoring



Security Monitoring is an add-on feature that allows for continuous monitoring of cloud resources for malicious activity. Potential security concerns are published to the Webscale Event Log where they can be reviewed and monitored in the Event Log Viewer.

## Configuring Security Monitoring

In order to configure security monitoring, your account must be granted access to the Security Monitoring plan. Please contact Webscale Support if you need this feature enabled for your account.

Once you have been granted access, click the three bars <i class="fa fa-bars" aria-hidden="true"></i> on the upper left and select the **Providers** tab. Select your AWS Provider or create one and check the box labeled "Use for Security Monitoring".

Note: At this time, AWS is the only supported Cloud Provider for Security Monitoring. If you are using a different provider, and would like to see this feature extended to that provider, please contact Webscale Support.

Once you click save, Security Monitoring has been enabled for this Provider. If you do not have access to the Security Monitoring feature, you will receive an error message at this time.

## What is Security Monitoring?

If you have configured security monitoring for your AWS Provider, you have enabled Amazon GuardDuty's Intelligent Threat Detection. You can read more about this [here](https://aws.amazon.com/guardduty/). All resources created with that AWS Provider will be monitored by the GuardDuty service for compromised accounts, anomalous behavior, and malware.

When a security finding is reported, it will be published to the Event Log with a type of "security-monitor-finding" along with details about the finding. You can use Webscale Monitors to configure notifications as well as automatic replacement of potentially compromised servers.

## Configuring a Webscale Monitor to alert on findings

Webscale Monitors can be used to send emails or VictorOp notifications when a security finding occurs. To set up a monitor for this purpose, create a new Monitor using the Monitors tab in the Site Menu.

- The monitor type should be "logs".
- No labels are necessary.
- Log type should be "Event logs".
- Measurement interval should be no less than 900 (15 minutes) as this is the frequency in which the underlying monitoring service runs.
- Condition should be "count>0" in order to be notified on any finding that is detected.
- Filter should be "type='security-monitor-finding'".
- Enter the email address you would like to be notified.
- Optionally: enter a custom message that will be included in the notification using the provided template.

Click "Save" and your Webscale Monitor will be active.

## Further reading

- [Working with Monitors](/docs/how-tos/advanced/monitors/)
- [Logs on Webscale](/docs/how-tos/advanced/logs/)
---
# Editing the Blocklist
URL: https://docs.webscale.com/docs/how-tos/security/blacklist/
Description: Add and remove IP addresses from the blocklist



Add IP addresses to the blocklist to block known-bad IPs from accessing the backend of your application. It's also possible to add User-Agents to the blocklist by defining a pattern to match. You should add known-good IP addresses to the allowlist to allow them to access your application. For more information on adding IP addresses to the allowlist, see [Editing the Allowlist](/docs/how-tos/security/whitelist/).

{{% alert title=Note %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

## Add an address set to the blocklist

Click **Blocklist** on the menu.

{{< figure src="/images/blacklist_1.png" alt="Webscale blacklist page in the control panel" >}}

Under the **Blocklist Address Set** section, click the drop-down menu and select an address set.

{{% alert title="Note:" %}}
The IP addresses in the address set will not be shown on this page.
{{% /alert %}}

## Add an IP Address

Click **Blocklist** on the menu.

Under **Blocklist by IP address**, enter the IP addresses or ranges separated by commas or spaces. In the **Description** text area, enter a description so you can remember why you created this entry. Next to this field is a slider to select the duration of the blacklist. To create a blacklist entry that never expires, leave it as-is. When finished, click the **Done** button to add the entry.

{{% alert title="Note:" %}}
If a **combined** or **manual** address set is selected above, addresses added here will be added to the manual address set that is referenced.
{{% /alert %}}

{{% alert title="Note:" %}}
If you choose "Never" on the expiration slider, the IP address will remain on the list forever.
{{% /alert %}}

The **Entries** section is below the **Blocklist by IP address** section. It lists currently blocklisted addresses, which contain the following information:
- IP address
- Label
- Expiration date
- Created date
- Creator

There are also two buttons: an edit button, and an **X** button that removes the IP address.

### Add an IP address from the Traffic Viewer

You can add IP addresses to the blocklist from Traffic Viewer. In the Traffic Viewer logs viewer, hover over the **Request Address**, **Peer Address**, **Server Address** or **Proxy Address** column, then click the small arrow that appears to display the popup menu. You can also right-click on any of the columns to bring up the pop-up menu. Once the menu is displayed, you can select **Add to blocklist “Blacklist”**.

### Add an IP address from the CSP Logs Viewer

You can add IP addresses to the blocklist from the CSP Logs Viewer. While in the CSP Logs Viewer, hover over the **Request Address** or **Peer Address** column, then click the small arrow that appears to display the pop-up menu. You can also right-click on any of the columns to bring up the pop-up menu. Once the menu is displayed, you can select **Add to blocklist “Blacklist”**.

### Add an IP address from the Pageviews Logs Viewer

You can add IP addresses to the blocklist from the Pageviews Logs Viewer. While in the Pageviews Logs Viewer, hover over the **Request Address** or **Peer Address** column, then click the small arrow that appears to display the pop-up menu. You can also right-click on any of the columns to bring up the pop-up menu. Once the menu is displayed, you can select **Add to blocklist “Blacklist”**.

When you add an entry to the blocklist from either the Traffic Viewer, CSP Logs Viewer, or Pageviews Logs Viewer, the entry will never expire. Note that the **Add to blocklist “Blacklist”** item will only appear if the blocklist is using either a **Manual** address set or a **Combined** address set that includes a manual set. If the option does not appear and you believe it should, you may have to reload the page.

## Edit an IP Address

To edit an IP address, click the edit button. Make any changes as explained above, and click the **Update** button. To cancel without making changes, click the **Cancel** button.

## Remove an IP Address

To remove the IP address, click the **X** button.

{{% alert title="Warning" color="warning" %}}
Be careful, this action is final.
{{% /alert %}}

## Blocklist by User-Agent

To blocklist by User-Agent, click the "Edit Pattern" button. Type the pattern you want to match, then click "Save Pattern" to save the changes.

{{% alert title="Note:" %}}
The pattern you use here must be a qualified regular expression. Find more information at [Regular Expressions](https://www.regular-expressions.info/).
{{% /alert %}}

## Further reading

- [Blacklisting Definition](https://en.wikipedia.org/wiki/Blacklisting)
- [Working with Address Sets](/docs/how-tos/general/address-sets/)
- [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)
- [Regular Expressions](https://www.regular-expressions.info/)
- [Editing the Whitelist](/docs/how-tos/security/whitelist/)
---
# Editing the Allowlist
URL: https://docs.webscale.com/docs/how-tos/security/whitelist/
Description: Add and remove IP addresses from the Allowlist


Add your local IP address to the Allowlist to ensure you always have access to the backend of your application. You should also add some IP addresses to the Blocklist to prevent them from accessing your application. You can find those instructions on [Editing the Blocklist](/docs/how-tos/security/blacklist/).

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

## Add an address set

Click **Allowlist** on the menu.

{{< figure src="/images/whitelist_1.png" alt="Webscale whitelist page in the control panel" >}}

Under the **Allowlist Address Set** section, click the drop-down menu and select an address set.

{{% alert title="Note:" %}}
The IP addresses in the address set will not be reflected on this page.
{{% /alert %}}

## Add an IP address

Click **Allowlist** on the menu.

Under **Allowlist IP address**, click the **Comma/space-separated IP addresses/CIDRS** text area and enter your IP addresses or ranges separated by commas or spaces. In the **Description** text area, enter a description so you can remember why you created this entry. Next to this field is a slider to select the duration of the allowlist. To create a allowlist entry that never expires, leave it as-is. When finished, click the **Done** button to add the entry.

{{% alert title="Note:" %}}
If a **combined** or **manual** address set is selected above, addresses added here will be added to the manual address set that is referenced.
{{% /alert %}}

{{% pageinfo color="info" %}}
If you do not know your local IP address, you can find it using a tool such as [whatsmyip.org](https://www.whatsmyip.org/).
{{% /pageinfo %}}

{{% alert title="Warning" color="warning" %}}
If you choose "Never" on the expiration slider, the IP address will remain on the list forever. We recommend choosing an expiration date instead of choosing "Never".
{{% /alert %}}

After the **Allowlist IP address** area is the **Entries** area. This shows a list of currently allowed  addresses, containing the following information:
- IP address
- Label
- Expiration date
- Created date
- Creator

There are also two buttons: an edit button, and an **X** button that removes the IP address.

### Add an IP address from Traffic Viewer

You can add IP addresses to the allowlist from Traffic Viewer. While in Traffic Viewer, hover over the **Request Address**, **Peer Address**, **Server Address** or **Proxy Address** column, then click the small arrow that appears to display the popup menu. You can also right-click on any of the columns to bring up the pop-up menu. Once the menu is displayed, you can select **Add to allow list “Whitelist”**.

### Add an IP address from the CSP Logs Viewer

You can add IP addresses to the allowlist from the CSP Logs Viewer. While in the CSP Logs Viewer, hover over the **Request Address** or **Peer Address** column, then click the small arrow that appears to display the pop-up menu. You can also right-click on any of the columns to bring up the pop-up menu. Once the menu is displayed, you can select **Add to allow list “Whitelist”**.

### Add an IP address from the Pageviews Logs Viewer

You can add IP addresses to the allowlist from the Pageviews Logs Viewer. While in the Pageviews Logs Viewer, hover over the **Request Address** or **Peer Address** column, then click the small arrow that appears to display the popup menu. You can also right-click on any of the columns to bring up the popup menu. Once the menu is displayed, you can select **Add to allow list “Whitelist”**.

When you add an entry to the allowlist from either the Traffic Viewer, the CSP Logs Viewer or the Pageviews Logs Viewer, the entry will expire after 1 week by default. Note that the **Add to allow list “Whitelist”** item will only appear if the Allowlist is using either a **Manual** address set or a **Combined** address set that includes a manual set. If the option does not appear and you believe it should, you may have to reload the page.

## Edit an IP Address

To edit an IP address, click the edit button. Make any changes as explained above, and click the **Update** button. To cancel without making changes, click the **Cancel** button.

## Remove an IP Address

To remove the IP address, click the **X** button.

{{% alert title="Warning" color="warning" %}}
Be careful, this action is final.
{{% /alert %}}

## Further reading

- [Whitelisting Definition](https://en.wikipedia.org/wiki/Whitelisting)
- [Working with Address Sets](/docs/how-tos/general/address-sets/)
- [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)
- [Editing the Blocklist](/docs/how-tos/security/blacklist/)
---
# How to Configure Multi-Factor Authentication
URL: https://docs.webscale.com/docs/how-tos/security/mfa/
Description: How to configure multi-factor authentication



Multi-factor authentication (MFA) is a way to help increase security by requiring users to authenticate with a device in addition to the standard username and password combination. Some examples of multi-factor authentication include SMS codes and authentication applications such as _Google Authenticator_ or _Authy_. Multi-factor authentication on Webscale uses authentication applications only.

## Configure multi-factor authentication (MFA)
<!-- TODO: Add screencaps -->
|   |   |
|---|---|
| {{< figure src="/images/roles-users/mfa-qr-code.png" alt="MFA QR Code" >}} | 1. To enable multi-factor authentication yourself while logged in, visit your [User Profile](https://control.webscale.com/profile) and click the **Enable MFA** button.<br /><br /> Otherwise, if the role a user belongs to requires multi-factor authentication, it must be configured when the user initially logs in to the control panel. When they login, the user sees a QR code. Use the authenticator application on the device to scan this QR code.<br /> {{< info-mark >}}Some examples of authenticator applications are _Google Authenticator_, _Authy_, _OnePassword_, etc. Please refer to the software installation instructions for your specific device. |
| {{< figure src="/images/roles-users/mfa-verify.png" alt="MFA Code Entry - Verification" >}} | 2. Once the user scans the QR code, the authenticator application on the user's device will generate a 6-digit code, called a One-Time Password (OTP).<br /> Enter the generated OTP into the text field on the control panel, and click the **Verify** button.{{< info-mark >}}To ensure the enrollment was done correctly, the user must confirm by entering their current password in the box that appears after entering the OTP.  |
| {{< figure src="/images/roles-users/mfa-code-entry.png" alt="MFA Code Entry - Login" >}} | 3. Multi-factor authentication for the user is now enabled.<br /> For future logins, the user must use the authenticator application on their device to generate an OTP after they've successfully authenticated with their password. Note that checking the box for **Remember this browser** will set a cookie so the MFA code is not needed again if you login from the same browser. {{< info-mark >}}Users follow a similar process, starting at the User Profile, to change or reset their multi-factor authentication application. The user must be able to login using their existing multi-factor authentication device to make changes. If the user changes devices or applications and cannot login, please [Contact Support](mailto:support@webscalenetworks.com). |

### Troubleshooting

If the MFA token being generated is not validating and allowing the user to login, it's possible the time settings for the user's mobile device and computer do not match. The specifics for resolving this issue differ depending on the mobile device OS and the computer OS in use. Here are some helpful resources:

- [About Time sync for Google Authenticator on Android](https://support.google.com/accounts/answer/2653433?hl=en)
- [How to set your time and time zone (Windows)](https://support.microsoft.com/en-us/windows/how-to-set-your-time-and-time-zone-dfaa7122-479f-5b98-2a7b-fa0b6e01b261)
- [If the date or time is wrong on your Mac](https://support.apple.com/en-us/HT203413)
- [If you can’t change the time or time zone on your iPhone, iPad or iPod touch](https://support.apple.com/en-us/HT203483)

If you continue to have issues with MFA, please [Contact Support](mailto:support@webscalenetworks.com).

## Further reading
- [How to Create Roles and Invite Users](/docs/how-tos/general/user-roles/)
- [How to Use Webscale Secure Access](/docs/how-tos/security/secure-access/)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Edit the Whitelist](/docs/how-tos/security/whitelist/)
- [How to Edit the Blacklist](/docs/how-tos/security/blacklist/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
---
# How to Use Webscale Secure Access
URL: https://docs.webscale.com/docs/how-tos/security/secure-access/
Description: How to use Webscale Secure Access.



[**User Roles**](/docs/how-tos/general/user-roles/) can be used as an action in an optional web control, called **Webscale Secure Access**, to protect sections of your application from the general internet. This increases security by ensuring that only users who you've invited and assigned to a role can access these sections. As an example, you can require users to use Webscale's login form before accessing your website's login form, and can enforce [multi-factor authentication (MFA)](/docs/how-tos/security/mfa/) for these users as well.

{{% alert color="warning" title="Note:" %}}
**Webscale Secure Access** is an optional feature. Please [contact your account manager](mailto:customersuccess@webscale.com) if you'd like to enable this feature for your account.
{{% /alert %}}

{{% alert title="Prerequisite" %}}
To use this web control, first create or edit a [**User Role**](/docs/how-tos/general/user-roles/) for the web control to use, and invite at least one user to the role.
{{% /alert %}}

## Create the Webscale Secure Access Web Control

The action `restrict-access` checks for a cookie stored in the user's browser to see if the user has any of the specified roles. If the user does have one of the roles and has logged into the Webscale control panel recently, the browser will supply the requested content. Otherwise, the user will be redirected to the Webscale control panel login page. After a successful login to the Webscale control panel with a user account that has the proper role, the browser will supply the requested content. If the user does not have the proper role, they will be forbidden from visiting the requested page and will have to accept the role invitation from the [User Profile](https://control.webscale.com/profile) before being able to proceed. The `restrict-access` action is a final action. Final actions run last; the order of execution of other actions is unspecified and not necessarily in the order displayed.

| | |
|:----|:---|
 {{< figure src="/images/roles-users/web-control-role-action.png" alt="Web Control - Restrict Access action" >}} | <ol><li>To configure this Web Control action, follow the steps on [How To Create a Web Control](/docs/how-tos/web-controls/webcontrols_create/).</li><li>For the action, specify **Restrict Access**. Click **Add Role...** to add the role you want this action to apply to, and select the role from the drop-down menu.</li><li>If you wish to remove a role, click the trash can <i class="fa fa-trash" aria-hidden="true"></i>.</li><li>When done, click the **Done** button to save.</li></ol> |

## Further reading
- [How to Create User Roles](/docs/how-tos/general/user-roles/)
- [How to Configure Multi-factor Authentication](/docs/how-tos/security/mfa/)
- [Web Controls](/docs/how-tos/web-controls/)
- [How to Block Countries from Accessing Your Site](/docs/how-tos/security/block-countries/)
- [How to Edit the Whitelist](/docs/how-tos/security/whitelist/)
- [How to Edit the Blacklist](/docs/how-tos/security/blacklist/)
---
# Enabling Bot IP Shield
URL: https://docs.webscale.com/docs/how-tos/security/bot-shield/
Description: Set up and enable Bot IP Shield in the Webscale Control Panel



Bot IP Shield is an add-on feature from Webscale that allows you to protect your application from known attack sources. Webscale has partnered with [Webroot’s BrightCloud® IP Reputation Service](https://www.brightcloud.com/) to maintain IP reputation data that is updated every 5 minutes to reflect the latest attack sources.

After enabling this feature, configure shielding for the application that you want to protect. Then, create Web Controls to handle traffic from sources that you consider a threat. For example, you could configure the Web Control to deny requests from a request IP if it is a known threat.

{{% alert title=Note %}}
Contact [support](mailto:support@webscalenetworks.com) for assistance when enabling this feature.
{{% /alert %}}

## Set up Bot IP Shield

 |  |
---------|----------|
|{{< figure src="/images/bot-shield/threat-webcontrol-1.png" width="75%" alt="Edit Web Control Box" >}}| **To add the Web Control**<br /><ol><li>On the **Web Controls** page, click **Add a Web Control**.</li><li>Enter a name and description for the new Web Control. Click **Add condition**.</li><li>From the condition drop-down menu, select **IP address is a Threat**</li><li>Click **Save**.</li></ol> |
|{{< figure src="/images/bot-shield/threat-webcontrol-2.png" width="75%" alt="Edit Web Control Box" >}} | **To configure the Web Control action**<br /><ol><li>Click **Add action**.</li><li>From the **Type** drop-down menu, select **Deny Request**. You can also edit the HTTP status code and response body.</li><li>Click **Add Action**.</li><li>Click **Done** to create the action.</li><li>On the **Web Controls** page, click **Done** to create the Web Control.</li></ol> |
|{{< figure src="/images/bot-shield/threat-webcontrol-3.png" width="75%" alt="Enable Bot IP Shield Web Control" >}}| **To enable the Web Control**<br /><ol><li>On the **Web Controls** page, select the Web Control.</li><li>Click the toggle for it.</li><li>Click the **Enable** checkbox.</li><li>Click **Apply**.</li><br />Webscale will now deny any request from an IP flagged as a threat. |
|{{< figure src="/images/bot-shield/threat-traffic-viewer-sort.png" width="75%" alt="Traffic Viewer Column Selection" >}}| You can configure Traffic Viewer to view threat requests from Traffic Viewer. For information on how to access Traffic Viewer for your application, see [To access Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/#to-access-traffic-viewer).<br /><br />**To add the threat column**<br /><ol><li>On the **Traffic Viewer** page for your application, click **Columns**.</li><li>Select the **Threat** checkbox.</li><br />You can now see the **Threat** label in the traffic data. |
|{{< figure src="/images/bot-shield/threat-traffic-viewer.png" width="75%" alt="Traffic Viewer Graph" >}}| You can filter traffic results to only display requests labeled as a threat.<br /><br />**To filter traffic for only requests tagged as a threat**<br /><ol><li>Access the **Traffic Viewer** page for your application.</li><li>Enter `threat=y` into the **Filter** field.</li><br />The records view of the query results only displays logs that match the filter criteria. |

## Further reading

 - [Introducing Application Shielding](/docs/reference/app-shield/)
 - [Configuring Application Shielding](/docs/how-tos/general/shielding/)
 - [How to Create Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
 - [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
 - [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
---
# How to Block Countries from Accessing Your Site
URL: https://docs.webscale.com/docs/how-tos/security/block-countries/
Description: How to use a Web Control to block certain countries from accessing your site.




It's possible to use a Web Control to block countries from accessing your application. This is done by using the `Country of origin is...` condition for the Web Control.

{{% alert %}}
{{% include dashboard-login.md %}}
On the menu that appears, click **Edit**.
{{% /alert %}}

## Create the Web Control

Click **Web Controls** on the menu. Then, click the **Add A Web Control** button to go to the **Edit Web Control** panel.

{{< figure src="/images/web_controls/create_main.png" alt="Webscale Web Controls page in the control panel" >}}

Type the name of the new Web Control in the **Name** field. Choose a unique, descriptive name and description to help you identify this Web Control in the future.

### Create the Condition

Click **+ Add condition** to create the condition to apply to the new Web Control, which opens the Create Condition dialog. To proceed, click **Select a Condition**. In this case, select **Country of origin is** from the selection list.

{{< figure src="/images/web_controls/create_condition.png" alt="Webscale Create Condition dialog in the control panel" >}}

Click on a country in the **Available Countries** list, then click the **Add&#x2192;** button to add it. To remove a country from the **Selected Countries** list, click the **&#x2190;Remove** button. Tip: Hold control (Windows) or command (macOS) when you click to select more than one country. Click **Done** after making your choices.

{{< figure src="/images/country-selection.png" alt="Webscale Create Condition dialog showing country selection" >}}

### Create the Action

Click **+ Add action** to create an action for the new Web Control, which opens the Create Action dialog. To proceed, click **Select an Action**. Choose **Deny Request** in this case. You can also choose the HTTP status code and Response Body if you like. Click **Done** after making your selection.

{{< figure src="/images/web_controls/create_action.png" alt="Webscale Create Action dialog in the control panel" >}}

Once you've made your selection, click **Done** to save the Web Control. Once back on the Web Controls list, click the checkbox for **Enabled** to enable the new Web Control, and then click **Apply** to apply the changes.

{{< figure src="/images/apply-changes.png" alt="Webscale Web Controls - apply changes" >}}

When a request is made from a country you've added to this list, then that request is dropped. The **Deny Request** action is a final action, and you can only choose one final action for each Web Control you create. Final actions run last; the order of execution of other actions is unspecified and not necessarily in the order displayed.

## Further Reading

- [How to Create Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
- [How To Shield Your Online Storefront From Cyberthreats With Webscale's Web Controls](https://www.webscale.com/blog/shield-online-storefront-cyberthreats-webscale-web-controls/)
- [What are Web Controls, and how do I use them?](/docs/faq/#what-are-web-controls-and-how-do-i-use-them/)
---
# Installing SSL Certificates
URL: https://docs.webscale.com/docs/how-tos/security/install-ssl/
Description: Install SSL certificates and enable Auto HTTPS and HSTS



E-commerce sites require encrypted connections to remain PCI complaint and accept credit card data. Encryption ensures secure transmission of credit card details, which prevents bad actors from intercepting the information. To encrypt connections for your website, you must have an SSL (TLS) certificate installed for your site. ("SSL" and "TLS" are widely-used acronyms for "Secure Sockets Layer" and "Transport Layer Security." SSL is now deprecated. TLS is the successor of SSL.)

Through the **HTTPS** page for your application, you can install or upload your own certificate. Alternately, you can enable the Auto HTTPS feature, so Webscale automatically obtains, installs, and maintains [Let's Encrypt](https://letsencrypt.org/) certificates for your site.

{{% alert title="Note:" %}}
When you have valid and signed certificates for your application, HTTPS is enabled for it.
{{% /alert %}}

You can also use this page to choose other certificate options, including enabling HSTS (HTTP Strict Transport Security) to ensure full encryption and compliance.

You can use the **HTTPS** page to perform the following operations.

- Install or upload a SSL certificate
- Enable the Auto HTTPS feature
- Restrict your site to only accept newer versions of certificates
- Offload HTTPS to terminate all HTTPS traffic at the data plane
- Prompt Webscale to validate your origin server's certificate
- Enable HSTS for your application

{{% alert title="Note:" %}}
If you are using self-signed certificates on your origin server, do not enable the Origin validation setting.
{{% /alert %}}

{{% alert title="Warning" color="warning" %}}
If you enable HTTPS, the traffic between Webscale and your origin servers will be unencrypted.
{{% /alert %}}

## Access the **HTTPS** page

### To access the **HTTPS** page

1. Click the three vertical dots menu icon <i class="fa fa-ellipsis-v" aria-hidden="true"></i> on the upper-right corner of the application box and select **Edit**.

    {{< figure src="/images/shared/select_edit_app.png" width="80%" alt="Select Edit from the application menu" >}}

    -or-

    On your application page, click the **Actions** menu icon and select **Edit**.

    {{< figure src="/images/shared/select_edit_app_action.png" width="35%" alt="Select Edit from the Action menu" >}}

2. On the sidebar menu, select **HTTPS**.<br />
    The **HTTPS** page displays.

    {{< figure src="/images/ssl/ssl_select_https.png" width="80%" alt="Select Edit HTTPS" >}}

## Install your own SSL certificate

To install an SSL (TLS) certificate for an application, paste the contents of a certificate and its key and chain into the **Certificate content** box. Or, you can upload one or more certificate files for your application. You must also upload the key files for the certificates. A single certificate can protect all of your domains. If you have multiple domains, you can install a certificate for each one.

### To install an SSL certificate

1. In the **HTTPS certificates** section, click the **Add a certificate** link. The **Add a TSL certificate** dialog box displays.

    {{< figure src="/images/ssl/ssl_click_add_cert_link.png" alt="Click Add Certificate link" >}}

2. In the **Certificate content** box, paste the contents of your SSL certificate, key, and chain files. Or, click **Choose files** to upload the certificate, key, and chain files.

    {{< figure src="/images/ssl/ssl_add_tls_cert_dialog.png" alt="Enter or upload certificate, chain, and key" >}}

3. Click **Add**.
    The certificate then displays in the **HTTPS certificates** list of certificates.
4. Click **Apply**.

{{% alert title="Note:" %}}
You must also install and update SSL certificates for other end points, such as web and redirect servers. Contact [support](mailto:support@webscalenetworks.com) if you want Webscale to complete this step.
{{% /alert %}}

## Enable the Auto HTTPS feature

If you don't own an SSL certificate or want to leverage the Auto HTTPS feature, you can enable this feature so Webscale will manage your certificates. For each application domain, Webscale will obtain and install a free [Let's Encrypt](https://letsencrypt.org) SSL certificate. To do so, it requests the certificates and creates the challenge files necessary to create them.

Let's Encrypt certificates expire after 90 days. Webscale automatically renews and updates each certificate.

{{% alert title="Note:" %}}
If Let's Encrypt does not automatically obtained your certificate within a few hours, contact [support](mailto:support@webscalenetworks.com).
{{% /alert %}}

### To enable the Auto HTTPS feature

1. In the **Auto HTTPS** section of the **HTTPS** page, click the toggle to enable or disable the Auto HTTPS feature.</br >
    Enabling this feature starts the certificate request and installation task.

    {{< figure src="/images/ssl/ssl_enable_auto_https.png" alt="Enable Auto HTTPS feature" >}}
2. Click **Apply**.
3. You can verify that you have successfully enabled this feature by viewing the status of the corresponding tasks and through the following procedure.<br />

    a. On the **Webscale Control Panel** page, click the menu icon <i class="fa fa-bars" aria-hidden="true"></i> on upper left of the screen.<br />
    b. Click **Tasks** on the sidebar menu to view the **Tasks** page. A list of current and recent tasks displays.
    {{< figure src="/images/https/auto-https.png" alt="Users List" >}}
    c. Click the **Obtain certificate** task to view information on the task status, certificate order, and HTTPS and DNS challenges.

The task will expire. If Let's Encrypt cannot verify the challenges within the specified expiration period, Webscale must make a new request. Contact [support](mailto:support@webscalenetworks.com) for assistance or if you have questions.

## Enable or disable HSTS

HTTPS (HyperText Transfer Protocol Secure), an encrypted version of the HTTP protocol, is a web security policy mechanism that helps protect websites against man-in-the middle attacks. These attacks include protocol downgrade attacks and cookie hijacking. It uses SSL or TLS to encrypt all communication between a client and a server. Through this secure connection, clients can safely exchange sensitive data with a server, such as when performing banking activities or online shopping.

When you enable HSTS, you increase the security of your application.

### To enable or disable HSTS

1. In the **HTTP Strict Transport Security (HSTS)** section of the **HTTPS** page, click the toggle to enable or disable HSTS.
2. Click **Apply**.

{{% alert title="Warning" color="warning" %}}
Enabling HSTS can break your website if you have links to external sites that do not have corresponding HTTPS URLs. Test all links on a staging or dev site before making this change. You must understand the risks before enabling HSTS.
{{% /alert %}}

## Enable or disable other HTTPS settings

You can use the following instructions to enable or disable the Protocols, HTTPS offload, and Origin validation settings.

### To enable or disable the other HTTPS settings

1. For each HTTPS setting, click the toggle to enable or disable it in the section for the setting.
2. Click **Apply**.

## Further reading

- [How to Contact Support](/docs/getting-started/support/)
- [Let's Encrypt (external link)](https://letsencrypt.org/)
- [HTTP Strict Transport Security (HSTS) (external link)](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)
---
# Troubleshooting and Researching a Security Breach
URL: https://docs.webscale.com/docs/how-tos/security/security-breach/
Description: Discover and troubleshoot a security breach of your application.



One of the most stressful things that can happen to an ecommerce business is to discover that your site has been hacked or otherwise compromised. Webscale offers protection to known attacks right out of the box, but there are additional steps you can take to increase the security of your site and prevent future attacks. These are accomplished through the usage of Web Controls. There are also some common steps you can take to find out if the site has already been compromised.

## General Instructions

Some common steps you can take to protect your sites from attack include the following:

 - Use [Web Controls](/docs/how-tos/web-controls/webcontrols_create/) to immediately block access to known vulnerable URLs or files. Example: {{< figure src="/images/security-breach/web-control-bad-urls.png" alt="Web Control for bad URLs" >}}
 - Add known bad IPs to the [Blacklist](/docs/how-tos/security/blacklist/) and good IPs to the [Whitelist](/docs/how-tos/security/whitelist/).
 - Protect your admin site with [Web Controls](/docs/how-tos/web-controls/webcontrols_create/), leveraging the whitelist or blacklist features.

If you suspect a breach or hack has taken place, you can use [Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/) to verify the attack vector used. Some useful columns to filter on include:

 - `delivery_status`: Identifies which part of the system responded to the traffic. Greater than -1 shows all status results. A result of `0 proxied` means the request went to the backend application servers - anything else is served by the proxy.
 - `request_path`: Path to the files used in the exploit.
 - `request_method`: POST or GET (most common).
 - `status_code`: The http status code the request received.
 - `request_address`: The address of the requestor - mainly used to check against whitelist or blacklist.

#### Example traffic viewer query:
```
delivery_status > - 1 and request_path ~ /downloader* and request_address not in whitelist and status_code = "403"
```
#### Example traffic viewer result:
{{< figure src="/images/security-breach/traffic-viewer-results.png" alt="Traffic Viewer filter results" >}}

## Magento 1 instructions

Here are a few of the security measures Webscale uses to protect M1 applications from exploits as part of our [Magento 1 EOL Support](/docs/reference/m1eol-support/):

 - Web controls to immediately block access to the downloader.
 - Real-time CSP alerting and blocking to ensure only pre-approved domains are executing scripts.
 - Web controls to protect admin page access, with whitelisting and multi-factor authentication.

Whether you have Magento 1 EOL Support or not, you can use Web Controls as explained above to protect your site from known exploits, and in many cases any exploit. Please [Contact Support](mailto:support@webscalenetworks.com) to learn more about Magento 1 EOL Support.

### Magento 1 CardBleed exploit

A recent use-case for these techniques is the [Magento 1 CardBleed](https://sansec.io/research/largest-magento-hack-to-date) exploit. Attackers used the `/downloader` path in Magento 1 to attack a large number of Magento 1 storefronts. This attack may look like the following, in your access logs:

{{< figure src="/images/security-breach/m1-attack-vector.png" alt="Magento 1 CardBleed attack vector" >}}

A traffic viewer query checking for requests to `downloader.php` should reveal quickly whether your site was compromised or not.

#### Example traffic viewer query:
```
delivery_status > - 1 and request_path ~ /downloader*
```

#### Example traffic viewer result:
{{< figure src="/images/security-breach/traffic-viewer-downloader-graph-2.png" alt="Magento 1 CardBleed traffic viewer graph" >}}

As you can see, on about September 3rd there was an uptick in requests that match our query. Thankfully in this case the requests ended up with a `403` http response, which means the site was protected from this exploit.

However, any results that show a `delivery_status` other than `9 denied` show that the file may have been successfully accessed. An http code of anything other than `403` is also suspect. You can use a Web Control to block all traffic to this file (which should no longer need to be used anyway) to protect against this attack as well as other exploits using the `downloader.php` file.

## Further Reading

 - [How to Edit the Blacklist](/docs/how-tos/security/blacklist/)
 - [How to Edit the Whitelist](/docs/how-tos/security/whitelist/)
 - [How to Create Web Controls](/docs/how-tos/web-controls/webcontrols_create/)
 - [Using Traffic Viewer](/docs/how-tos/traffic-viewer/traffic-viewer/)
 - [Building Filters in Traffic Viewer](/docs/how-tos/traffic-viewer/filter-traffic-viewer/)
---
# Security How-To Guides
URL: https://docs.webscale.com/docs/how-tos/security/
Description: Guides on securing your applications with Webscale


---
# SSH Connect
URL: https://docs.webscale.com/docs/how-tos/ssh-connect/
Description: Guides on using SSH Connect through the Webscale Control Panel


---
# SSH Gateway
URL: https://docs.webscale.com/docs/how-tos/ssh-gateway/
Description: Guides on using SSH Gateway to access your hosts with SSH, SCP, and SFTP


The Webscale SSH Gateway is a service that allows access to servers using
standard [Secure Shell](https://en.wikipedia.org/wiki/Secure_Shell) tools
like SSH, SCP, and SFTP to perform remote logins, file transfers, and
port forwarding while supporting role-based authorization and audit logging.
---
# Webscale Monitoring Agent
URL: https://docs.webscale.com/docs/how-tos/webscale-monitoring-agent/
Description: Guides on using the Webscale Monitoring Agent (WMA)



WMA is a multipurpose program that can be installed on a host to facilitate communication with Webscale. It is composed of three independent processes: metric monitoring, log collection, and ssh connectivity.
---
# About bot attacks
URL: https://docs.webscale.com/docs/explanation/explanation-about-bot-attacks-commerce-sites/
Description: This page explains the kinds of automated attacks we see against commerce sites, why carding is usually a bigger problem than DDoS, and how Webscale’s platform is positioned to help.

Use this as background reading before you configure specific defenses such as rate limits or Content Security Policy (CSP).



## What attackers are trying to do

Most attacks we see on commerce sites are **profit-driven**, not purely destructive.

Broadly, attackers want to:

- **Test stolen payment cards** to see which ones are still valid (carding).
- **Abuse business logic** such as coupons, loyalty points, or free-trial flows.
- **Harvest data** from product catalogs or customer accounts.

The goal is nearly always to turn someone else’s infrastructure and payment flows into **cheap testing infrastructure** for stolen data.

---

## Carding attacks vs “classic” DDoS

People often worry first about **DDoS** – trying to knock the site offline. That can happen, but on most commerce sites it’s:

- **Less common** than carding and fraud automation.
- **Less profitable** for attackers than quietly testing cards at scale.

In a **carding attack**, bots:

- Take a list of stolen card numbers.
- Send many small payment attempts against your checkout flow.
- Use your site (and your payment provider) to discover which cards are still “alive”.

From your point of view, this shows up as:

- Spikes in **failed transactions**.
- Complaints from your **payment provider** about fraud patterns.
- Higher downstream costs, even when charges are declined.

DDoS is about **availability** (can users reach the site at all?).
Carding is about **abuse of your payment flow** (can attackers cheaply test cards through you?).

---

## How bots actually behave

Modern carding bots rarely just hammer from a single IP. Common patterns include:

- **Distributed traffic** using botnets or cloud providers.
- **Replay attacks** using the same session or cookie across many requests.
- **Slow, low-and-slow patterns** designed to look like real users.

This is why a simple **“N requests per IP per minute”** rule is often not enough:

- Attackers can rotate IPs.
- They may keep each IP’s rate just below naïve thresholds.
- The real signal might be *“too many attempts per session or per account”* over a long window.

---

## Where Webscale sits in the flow

Webscale acts as a **defensive man-in-the-middle** between your users and your origin:

- All traffic flows through the Webscale proxy first.
- The proxy can inspect each request and response.
- It can enforce rules independently of your application code.

This position lets us:

- Enforce **global policies** consistently across all frontends.
- Apply protections even when your application stack is hard to change.
- Observe and correlate behavior across IPs, sessions, and endpoints.

You can think of this as a **smart shield** in front of your app: the shield decides what to pass on, what to modify, and what to block.

---

## Native protections vs web controls

Webscale has **native protections** baked into the platform (for example, baseline DDoS protections and traffic shaping) that operate automatically.

On top of that, you can add **web controls**, which are:

- **Customer-defined rules** that inspect requests and responses.
- Evaluated **top-down**, with conditions and actions.
- A way to express your own security and routing policies without code changes.

Some examples of what web controls can express:

- “If the URL matches `/checkout/payment` and the request has exceeded its rate limit, deny the request.”
- “If the site is in maintenance mode, show a maintenance page to the world but allow this address set to pass through.”
- “Add or enforce CSP headers on responses to specific paths.”

Think of native protections as **the platform’s baseline safety net**, and web controls as a **policy language** you use to tune that safety to your application and threat model.

---

## Why rate limiting matters for carding

Rate limiting is one of the most effective defenses against carding because it **raises the attacker’s cost**.

Done well, rate limiting can:

- Cap the number of payment attempts per **IP** or **session** over a long window (for example, per day).
- Make large card lists much slower and more expensive to test.
- Leave normal users largely unaffected, because real customers don’t make hundreds of payment attempts.

The key design questions for rate limits are:

- **Identity** – what are you limiting per *what*? IP, session ID, account, or some combination.
- **Threshold** – how many attempts are reasonable for a legitimate user.
- **Window** – over what period (minutes, hours, days) you measure that threshold.

These details are handled in your **rate-limiting web controls**. The separate how-to guide walks through implementation; this page just explains *why* those choices matter.

---

## Why CSP at the proxy helps

**Content Security Policy (CSP)** is a browser feature that limits which domains your pages can load scripts, images, and other resources from.

Enforcing CSP from the Webscale proxy has two big advantages:

1. **Central control**
   - You don’t need to update templates or code everywhere to change CSP.
   - You can introduce CSP gradually, per path or per site.

2. **Visibility into reports**
   - You can direct CSP violation reports to Webscale, giving you insight into unexpected behavior.
   - This helps detect malicious injections or unexpected third-party scripts.

CSP doesn’t block carding directly. Instead, it:

- Reduces the surface for injected scripts and malicious widgets.
- Makes it harder for attackers to exfiltrate data from your pages.
- Gives you more observability into unusual client-side behavior.

---

## How these pieces fit together

Putting it all together for commerce sites:

- **Bot and fraud attacks** are predominantly about abusing your legitimate flows.
- **Webscale’s position as a proxy** lets us observe and control these flows without touching your app code.
- **Web controls** are your language for expressing protection policies (conditions and actions).
- **Rate limiting** makes automated testing of cards more expensive and less attractive.
- **CSP** tightens client-side behavior and gives you visibility into suspicious front-end activity.

Once you’re comfortable with this mental model, you can move on to:

- Setting up **rate limits for carding protection** (how-to guide).
- Configuring **CSP via web controls** (how-to guide).
- Looking up specific actions and conditions in the **web controls reference**.
---
# App Testing
URL: https://docs.webscale.com/tags/app-testing/


---
# Application Testing
URL: https://docs.webscale.com/tags/application-testing/


---
# build-php-image
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/commands/build-php-image/
Description: Build a custom PHP image for an Essentials server


### Synopsis

* `build-php-image`

### Description
This command applies only to the **Essentials** tier. Higher tier environments
use [CodeDirect](/docs/how-tos/codedirect/) to create container images and deploy
them on clusters.

This command takes no arguments and uses `/etc/php/image/Dockerfile` to build a
custom image for the stack. Once complete, the
[`dev`](/hosting-platforms/hosting-v4/commands/dev/) command will utilize the
custom image, as will
[`php-fpm`](/hosting-platforms/hosting-v4/services/php-fpm/) after a restart.
---
# crontab-edit
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/commands/crontab-edit/
Description: Edit core server crontab for `www-data`


### Synopsis

* `crontab-edit`

### Description
On an essentials or core server, allows editing the crontab for the user
`www-data`. Ensure that the following lines are in the crontab before any
commands are specified, which will cause the crons to run in an application
environment by using the [`dev`](/hosting-platforms/hosting-v4/commands/dev/)
shell. Logs are written to `/var/log/php-fpm/cron.log`.

```sh
SHELL=/opt/webscale/bin/dev
DEV_LOG=/var/log/php-fpm/cron.log
```
---
# dev
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/commands/dev/
Description: Run a shell within an application environment


### Synopsis

**dev** [**-i**] [**-c** command]

Run an interactive shell or command in a temporary container.

**dev** **-w** [**-i**] [**-c** command]

Run an interactive shell or command in the live web server container of an
**Essentials** server.

### Options

**-c**
: Command. Runs a specified command.

**-i**
: Interactive. This maps standard input to the created process. This is the
  default if no arguments are given.

**-w**
: Web server container. Connect to the currently live web server container. This
  works on an **Essentials** server where a web server container is running or
  on a web server cluster server.

### Description

Run an interactive shell or a specified command in an application container.
When not attaching to an existing web container, the environment is established
exactly as when starting the web container. Shared entries from the shared
file system (`/var/www` for a core server and `/share/www` for a web server),
are mounted at `/var/www` in the created container. Changes that are made to
the filesystem that are not shared will be lost when the shell exits.
---
# Webscale Documentation
URL: https://docs.webscale.com/
Description: Everything you need to build, deploy, and manage your infrastructure.


<style>
  .td-main {
    min-height: 100vh;
  }
</style>

{{< blocks/section color="primary-bg-subtle" >}}
<div class="text-center mb-4">
  <h1 class="display-4">How can we help you?</h1>
  <p class="lead">Search our documentation or browse the categories below.</p>
</div>

<form class="td-search" style="max-width: 600px; margin: 2rem auto;">
  <input type="search" class="form-control form-control-lg td-search-input" placeholder="Search the docs..." autocomplete="off">
</form>
{{< /blocks/section >}}
<br>

## Core Platforms & Services
---
{{< cardpane >}}
  {{% card %}}
  ### [{{< fa icon="fas fa-brain" >}}Agentic Commerce OS](/docs/agentic-commerce-os/ai-explanation/)
  Configure, deploy, and scale your AI-driven storefronts.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-server" >}}Hosting Platforms](/hosting-platforms/)
  Understand infrastructure capabilities and configure your hosted environments.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-globe" >}}The Webscale Service](/docs/overview/dashboard/)
  Learn how to route traffic, cache content, and scale globally.
  {{% /card %}}
{{< /cardpane >}}

<br>

## Developer & Access Tools
---

{{< cardpane >}}
  {{% card %}}
  ### [{{< fa icon="fas fa-code" >}}API Reference](/docs/api/)
  Build an integration with the Control Plane.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-sliders-h" >}}Web Controls](/docs/how-tos/web-controls/)
  Manage your application behavior via controls in the data plane.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-terminal" >}}SSH Connect](/docs/how-tos/ssh-connect/)
  Access your servers securely with the click of a button.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-laptop-code" >}}CodeDirect](/docs/how-tos/codedirect/)
  Build and deploy container images automaically.
  {{% /card %}}
{{< /cardpane >}}

<br>

## Resources & Support
---

{{< cardpane >}}
  {{% card %}}
  ### [{{< fa icon="fas fa-book" >}}Reference Materials](/docs/reference/)
  Look up detailed specs, definitions, and comprehensive reference lists.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-images" >}}Hosting Images](/docs/reference/images/)
  Browse OS and application image catalogs.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-life-ring" >}}Magento 1 EOL](/docs/reference/m1eol-support/)
  Find security patches and support.
  {{% /card %}}
{{< /cardpane >}}
---
# Webscale Documentation
URL: https://docs.webscale.com/docs/
Description: Everything you need to build, deploy, and manage your infrastructure.


<style>
  .td-main {
    min-height: 100vh;
  }
</style>

{{< blocks/section color="primary-bg-subtle" >}}
<div class="text-center mb-4">
  <h1 class="display-4">How can we help you?</h1>
  <p class="lead">Search our documentation or browse the categories below.</p>
</div>

<form class="td-search" style="max-width: 600px; margin: 2rem auto;">
  <input type="search" class="form-control form-control-lg td-search-input" placeholder="Search the docs..." autocomplete="off">
</form>
{{< /blocks/section >}}
<br>

## Core Platforms & Services
---
{{< cardpane >}}
  {{% card %}}
  ### [{{< fa icon="fas fa-brain" >}}Agentic Commerce OS](/docs/agentic-commerce-os/ai-explanation/)
  Configure, deploy, and scale your AI-driven storefronts.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-server" >}}Hosting Platforms](/hosting-platforms/)
  Understand infrastructure capabilities and configure your hosted environments.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-globe" >}}The Webscale Service](/docs/overview/dashboard/)
  Learn how to route traffic, cache content, and scale globally.
  {{% /card %}}
{{< /cardpane >}}

<br>

## Developer & Access Tools
---

{{< cardpane >}}
  {{% card %}}
  ### [{{< fa icon="fas fa-code" >}}API Reference](/docs/api/)
  Build an integration with the Control Plane.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-sliders-h" >}}Web Controls](/docs/how-tos/web-controls/)
  Manage your application behavior via controls in the data plane.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-terminal" >}}SSH Connect](/docs/how-tos/ssh-connect/)
  Access your servers securely with the click of a button.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-laptop-code" >}}CodeDirect](/docs/how-tos/codedirect/)
  Build and deploy container images automaically.
  {{% /card %}}
{{< /cardpane >}}

<br>

## Resources & Support
---

{{< cardpane >}}
  {{% card %}}
  ### [{{< fa icon="fas fa-book" >}}Reference Materials](/docs/reference/)
  Look up detailed specs, definitions, and comprehensive reference lists.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-images" >}}Hosting Images](/docs/reference/images/)
  Browse OS and application image catalogs.
  {{% /card %}}

  {{% card %}}
  ### [{{< fa icon="fas fa-life-ring" >}}Magento 1 EOL](/docs/reference/m1eol-support/)
  Find security patches and support.
  {{% /card %}}
{{< /cardpane >}}
---
# Hosting Platforms
URL: https://docs.webscale.com/hosting-platforms/
Description: Hosting platforms


Webscale’s hosting platforms have a long history of continuous evolution,
culminating in our new fourth-generation (V4) infrastructure. While our robust
V3 platform currently powers the majority of our active workloads, V4 represents
the next leap forward in systems engineering, security, and performance.
---
# Image monitor
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/image-monitor/
Description: Core server monitor to update image used by the `dev` command to the one
currently in use by a stack.


To configure the image monitor, provide values in `/etc/image-monitor.env`
and issue the command `sudo systemctl enable --now image-monitor`. Logs are in
`/var/log/image-monitor.log`.

```sh
# Set the cluster id whose CONTAINER_IMAGE_URI metadata setting is used to
# update the local variables.php.image_uri stacker variable that is propagated
# to PHP_IMAGE_URI in the /etc/php/php-fpm.env on each update.
CLUSTER_ID=""

# The token used must be allowed to GET /v2/clusters in the account whose image
# is being monitored.
WEBSCALE_API_TOKEN=""
```
---
# Load Testing
URL: https://docs.webscale.com/tags/load-testing/


---
# M1
URL: https://docs.webscale.com/tags/m1/


---
# Magento 1
URL: https://docs.webscale.com/tags/magento-1/


---
# Magento 1 EOL
URL: https://docs.webscale.com/tags/magento-1-eol/


---
# MySQL
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/mysql/
Description: Run [MySQL](https://www.mysql.com) or [MariaDB](https://mariadb.org) on a core
server.



## Stack variables

### mysql.variant

Default: `mysql`. One of `mysql` or `mariadb`.

The service is always named `mysql`, even when a `mariadb` variant is used.

### mysql.version

Default: `8.4` for variant `mysql`. `10.11` for variant `mariadb`.

This version can be any version published as an Docker Official Image.

### mysql.snapshot_identifier

Specifies whether or not to create this database from a snapshot. This corresponds to the snapshot ID you'd find in the RDS console, e.g: rds:production-2015-06-26-06-05.
---
# OpenSearch
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/opensearch/
Description: Run an [OpenSearch](https://opensearch.org) search engine on a core server.



## Stack variables

### opensearch.memory

Default `512m`. Specifies amount of heap allocated to the OpenSearch process
with `-Xms` and `-Xmx`.
---
# PHP-FPM
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/php-fpm/
Description: Run a PHP-FPM web container on a core server (Essentials) or on a web server.


The `php-fpm` service is started to serve a PHP application for all PHP stack
types: `magento`, `shopware`, and `wordpress`. It runs in a container with a
tiny built-in HTTP <-> FastCGI proxy that configures its behavior according to
the stack type.

## Stack variables

### php.version

When a custom image is not used, sets the PHP version of the [php container
image](/docs/reference/images/) used.

### php.image_uri

Specifies a custom image to run in a PHP-FPM web container and the `dev`
command. This should usually not be configured in the stack variables directly
and is automatically set when a custom image for a cluster or Essentials server
is used. For Standard stacks and higher, the use of
[CodeDirect](/docs/how-tos/codedirect/) allows for custom images to
automatically be configured on a web server, and when combined with the [image
monitor](/hosting-platforms/hosting-v4/services/image-monitor/), on the core
server.

### PHP ini settings

| Variable                            | php.ini setting                 | Default |
|---                                  |---                              |---      |
| php.max_input_vars                  | max_input_vars                  | 10000   |
| php.memory_limit                    | memory_limit                    | 1G      |
| php.opcache.interned_strings_buffer | opcache.interned_strings_buffer | 32      |
| php.opcache.max_accelerated_files   | opcache.max_accelerated_files   | 100000  |
| php.opcache.memory_consumption      | opcache.memory_consumption      | 512     |
| php.opcache.validate_timestamps     | opcache.validate_timestamps     | 0       |
| php.post_max_size                   | post_max_size                   | 260M    |
| php.realpath_cache_size             | realpath_cache_size             | 4M      |
| php.realpath_cache_ttl              | realpath_cache_ttl              | 600     |
| php.upload_max_file_size            | upload_max_file_size            | 256M    |

## Magento env.php

The V4 stack provides a file `/etc/php/env.php` that contains a partial `env.php`
that can be merged at runtime with the complete settings provided in your
Magento settings. If you modify your `env.php` as follows, you can
pick up those settings while still allowing for future stack changes to automatically
occur.
```php
<?php
return array_replace_recursive(
    [
        'db' => [
            // ... settings ...
        ],
        // ... settings ...
    ],
    file_exists('/etc/php/env.php') ? include('/etc/php/env.php') : []
);
```
---
# RabbitMQ
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/rabbitmq/
Description: Run RabbitMQ on a core server.


This server utilizes the latest version published in the [image
catalog](/docs/reference/images/).
---
# rabbitmqctl
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/commands/rabbitmqctl/
Description: Tool for managing RabbitMQ nodes



This is has identical options and behavior to the RabbitMQ
[**rabbitmqctl**](https://www.rabbitmq.com/docs/man/rabbitmqctl.8) command.
---
# Security Stance On Unbutu Package Versions
URL: https://docs.webscale.com/docs/explanation/explanation-security-stance-on-unbuntu-package-versions/
Description: This page explains The Philosophy of Stability vs. Versioning


## **Introduction**

At Webscale, we prioritize the long-term stability and security of our customer environments. A frequent question arises: *"Why is Webscale using an older version of Nginx instead of the latest mainline release?"* To understand our stance, one must understand the trade-off between **feature velocity** and **proven stability**, and how the Linux ecosystem manages security through a process called "Backporting."

## **The "Latest" vs. "Secure" Myth**

In the world of consumer software (like phone apps), a higher version number almost always means better security. In enterprise server infrastructure, this isn't always the case.

"Mainline" or "Latest" releases often include:

* **New Features:** These introduce fresh code, which inevitably introduces fresh, undiscovered bugs.
* **Architectural Changes:** These can break existing configurations or third-party modules.
* **Short Support Windows:** Upstream developers move fast and often stop patching older "mainline" versions quickly.

## **Why Webscale Chooses Ubuntu LTS Packages**

Webscale utilizes packages from Ubuntu’s Long Term Support (LTS) repositories. This choice is based on a "Stability-First" philosophy:

### **1\. The Value of Canonical’s Vetting**

When we use an official Ubuntu package, we aren't just using a piece of software; we are leveraging the security team at Canonical. They act as a massive filter, rigorously testing security patches before they ever reach a production server. This offloads the risk of "regression" (where a security fix accidentally breaks a different feature) from Webscale and our customers onto a global team of specialists.

### **2\. Backporting: Security Without the Risk**

The most critical concept in our strategy is **Backporting**. Instead of jumping to a brand-new version of Nginx to get a security fix, the security patch is "backwards-ported" into the current, stable version.

This gives our customers the best of both worlds:

* **The security** of the latest fix.
* **The stability** of a version that has been running without issues for months or years.

## **Conclusion: Reliability as a Service**

While it may appear that a system is "out of date" based on a version number, the underlying security posture is identical to the latest release, but with significantly lower operational risk. By sticking to vetted, backported packages, Webscale ensures that a security update never becomes a "breaking" update.
---
# Supervisor
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/supervisor/
Description: Run [Supervisor](https://supervisord.org) on a core server.



## Configuration files

Configuration files may be placed on the core server host in directory
`/etc/supervisor` or in the container image in directory
`/etc/supervisor/conf.d`. Configuration files must have the suffix `.conf`.
Host configuration will override container image configuration.

## Enabling

This is an optional service, enable it with `sudo systemctl enable --now
supervisor`.

## Control

The [supervisorctl](/hosting-platforms/hosting-v4/commands/supervisorctl/) may
be run on the core server host.
---
# supervisorctl
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/commands/supervisorctl/
Description: Query and control a supervisord process



This has identical options and behavior to the Supervisor
[**supervisorctl**](https://supervisord.org/running.html#running-supervisorctl)
command.
---
# Understanding Agentic Commerce OS
URL: https://docs.webscale.com/docs/agentic-commerce-os/ai-explanation/understanding-agentic-commerce-os/
Description: Understand Webscale Agentic Commerce OS, the connected architecture that combines structured first-party behavioral data, AI-powered segmentation, and conversational storefront execution to support more adaptive, AI-native commerce.



Webscale Agentic Commerce OS is a connected operating model for AI-native commerce. It combines three layers of capability: a Customer Data Platform (CDP) that structures first-party behavioral data, AI Segmentation that turns that data into usable audience intelligence, and an AI Shopping Assistant that applies that intelligence in customer-facing storefront experiences. The name is deliberate. Each layer operates as an agent: observing behavior, making decisions, and taking action without waiting for manual instruction. That means segments update as shoppers act. Recommendations adjust to what a buyer is doing right now. And customer-facing interactions, from product discovery to order management to returns support, happen inside a single, continuously learning system rather than across disconnected tools.

What makes Agentic Commerce OS distinct is not simply that these capabilities exist together. It is that they are designed to work in sequence. Webscale frames the system around a clear progression: capture behavior, refine intent, and execute intent. Capturing behavior means structuring every storefront signal into a clean data foundation: page views, cart activity, and purchase records. Refining intent means turning that foundation into usable audience intelligence through plain-language interaction, without SQL or a data team. Executing intent means applying that intelligence directly in the storefront, so shoppers get relevant discovery, comparison, and support in real time.

## **What Agentic Commerce OS is**

Agentic Commerce OS is Webscale's architecture for connecting data, intelligence, and execution inside a single commerce model.

The CDP forms the foundation by capturing and structuring first-party behavioral data in real time. AI Segmentation builds on that foundation by turning business questions into deterministic audience logic and analytical answers through natural-language interaction. The AI Shopping Assistant then applies that intelligence directly to the storefront through conversational product discovery, comparison, Q\&A, and support.

When the layers work together, those returns compound: each one making the others more effective. But the decision to start anywhere in the stack is a valid one.

## **Why commerce needs a different operating model**

Modern commerce has two related problems.

On the shopper side, many storefronts still depend on static navigation patterns. Customers are expected to translate what they want into keywords, filters, and category paths. On the business side, the data needed to understand those customers is often fragmented across analytics tools, marketing platforms, and warehouses.

That fragmentation creates friction in both directions. Shoppers struggle to reach the right product efficiently, and teams struggle to turn behavior into usable insight quickly. Agentic Commerce OS is designed to connect those two sides of the problem instead of treating them as separate issues.

## **The three-layer model**

Agentic Commerce OS is easiest to understand as a three-layer model.

The first layer is the Webscale CDP. It captures storefront behavior and structures it into shopper profiles, behavioral histories, product interaction records, and revenue attribution.

The second layer is AI Segmentation. It uses that structured behavioral data to turn plain-language business questions into deterministic segments and insights. Those segments activate directly to Klaviyo, Magento, and connected marketing platforms. No CSV exports, no manual uploads. As shoppers interact with the storefront, segment membership updates automatically, and campaign performance is trackable against the same behavioral data that built the audience.

The third layer is the AI Shopping Assistant. It uses structured product and behavioral data to power a conversational agent embedded directly in the storefront. That agent handles the full buying journey: helping shoppers discover products, compare options, and ask product questions before purchase, and managing order status, returns, and support inquiries after. Each capability is modular and governed: the assistant routes each interaction to the right function automatically, without open-ended responses outside its defined scope.

## **Why the sequence matters**

The central idea behind Agentic Commerce OS is that reliable execution depends on reliable refinement, and reliable refinement depends on structured data.

Each layer delivers standalone value. The CDP structures first-party behavioral data that any downstream tool can use. AI Segmentation creates precise, dynamically updated audiences without requiring the AI Shopping Assistant. The AI Shopping Assistant improves discovery and conversion on any storefront with a clean product data foundation.

What the sequence adds is compounding returns. Segmentation built on CDP behavioral data is more accurate than segmentation built on imported lists. A Shopping Assistant grounded in real purchase and browsing history is more relevant than one running on catalog data alone. Merchants who deploy the full stack get a system where each layer makes the others more effective, not three products that happen to share a contract.

## **How the layers work together**

A shopper interaction begins as behavioral data. Page views, product views, cart activity, transactions, and session behavior are captured and structured by the CDP.

That foundation supports two distinct value streams that can be accessed independently. For marketing and analytics teams, AI Segmentation converts behavioral data into targetable audiences and plain-language business intelligence, available without deploying the AI Shopping Assistant. For shoppers, the AI Shopping Assistant uses structured product and behavioral data to guide discovery, comparison, and support in real time, available without the full segmentation stack. Merchants who want both get a system where each stream reinforces the other.

In that sense, Agentic Commerce OS connects two forms of intent. Business intent becomes audience intelligence. Shopper intent becomes guided execution. Structured data is what allows both to happen inside the same system.

That same structured data foundation also positions merchants for AI-mediated commerce beyond their own storefront. [Google's Universal Commerce Protocol (UCP)](https://developers.google.com/merchant/ucp) and [OpenAI's Agentic Commerce Protocol (ACP)](https://developers.openai.com/commerce), co-developed with Stripe, are defining how AI systems discover products, surface recommendations, and route buyers toward purchase inside conversational interfaces. Both require clean, synchronized, first-party behavioral and catalog data to represent a merchant accurately. Merchants on Webscale are building that infrastructure as part of normal commerce operations, not as a separate integration project. The CDP structures the data. The AI layers act on it. And the same foundation that powers on-site intelligence makes that merchant's catalog legible to the AI ecosystems where the next generation of buyers will discover products.

## **Why it is called agentic**

In Webscale's framing, commerce is shifting from static flows toward more conversational and intent-driven experiences.

Traditional e-commerce is organized around browse, filter, search, and compare. The shift underway moves toward ask, compare, and buy. That changes the role of the system. Instead of passively presenting pages and waiting for users to navigate them, the system helps interpret intent and move the interaction toward an outcome.

That is what makes the model agentic. It is not only storing data or exposing tools. It is coordinating data, interpretation, and execution across connected layers so that intent can be understood and acted on.

## **Why structured first-party data is foundational**

Agentic Commerce OS depends on structured first-party data because AI systems are only as useful as the data they can rely on.

Webscale places the CDP at the infrastructure layer rather than treating it as a separate add-on. That means behavioral data is captured at the source, kept current, and made available to downstream intelligence and execution layers. In this model, structured data is not a supporting detail. It is the prerequisite for reliable segmentation, trustworthy business intelligence, and behavior-aware shopper experiences.

This is also why Agentic Commerce OS is positioned as infrastructure for AI-native commerce rather than as a single storefront feature.

## **Why Agentic Commerce OS matters**

Commerce is becoming more conversational, more intent-driven, and more dependent on structured data that AI systems can use reliably.

That raises the standard for what a commerce platform needs to do. It is no longer enough to store catalog data, run campaigns, or serve static storefront pages in isolation. Merchants need a system that can connect behavioral data, business intelligence, and shopper-facing execution in a way that supports both present-day commerce operations and emerging AI-mediated buying experiences.

Agentic Commerce OS matters because it is Webscale's answer to that shift. It is designed to help merchants move from fragmented systems and static experiences toward a more adaptive, AI-ready commerce model.

## **Summary**

Agentic Commerce OS is Webscale's connected model for AI-native commerce. It combines a first-party behavioral data foundation, a natural-language intelligence layer, and a shopper-facing execution layer into one architecture.

Its purpose is not simply to add AI features to commerce. Its purpose is to make data, intent, and execution work together.
---
# Understanding AI Segmentation
URL: https://docs.webscale.com/docs/agentic-commerce-os/ai-explanation/understanding-ai-segmentation/
Description: Understand Webscale AI Segmentation, the intent refinement layer that uses structured first-party behavioral data from the CDP to turn natural-language questions into deterministic audiences and actionable insights.


## **What AI Segmentation is**

AI Segmentation is Webscale's intent refinement layer. It sits on top of the Webscale Customer Data Platform (CDP), where first-party commerce behavior is already captured and structured, and makes that data usable through plain-language questions instead of manual query building.

A marketer, analyst, or commerce operator can describe an audience in everyday language, and the system translates that intent into the right query against structured behavioral data. The result is an audience, answer, or insight grounded in actual shopper activity rather than a disconnected report or a manual rules workflow. That audience can then be pushed directly to Klaviyo, Magento, or connected marketing platforms for campaign activation. And because the segment is built on the same behavioral data that continues to update as shoppers interact with the storefront, campaign effectiveness can be tracked against real activity rather than estimated after the fact.

## **Why segmentation is difficult in commerce**

Segmentation is rarely limited by a lack of questions. It is limited by the distance between a business question and the data needed to answer it.

In most commerce environments, customer signals are spread across analytics tools, marketing platforms, dashboards, and warehouses. That fragmentation slows down audience creation and makes business users dependent on specialists to build reports, write queries, or maintain segment logic. By the time an audience is ready, the opportunity that made it relevant may have already passed.

AI Segmentation addresses that gap by reducing the work required to move from business intent to usable audience logic.

## **Why the CDP comes first**

AI Segmentation depends on the Webscale CDP because segmentation is only as reliable as the data beneath it.

The CDP captures first-party commerce behavior in real time and structures it into usable records such as shopper profiles, behavioral histories, product interaction records, and revenue attribution. That structure matters because it gives segmentation a dependable foundation. Without it, audience creation becomes an exercise in approximation across incomplete, delayed, or disconnected data.

In Webscale's model, segmentation is not the starting point. Structured behavioral data comes first. AI Segmentation builds on that foundation.

## **How AI Segmentation works**

At a high level, AI Segmentation converts business intent into segment logic.

A user might ask for high-value customers who have not purchased recently, shoppers who repeatedly viewed a category without converting, or customers whose behavior suggests churn risk. The system interprets that request, determines the appropriate query path, and returns a live result based on the merchant's structured behavioral data.

From the user's perspective, the interaction is conversational. Underneath, the outcome is operational: a defined audience, an analytical answer, or a result that can be used downstream.

## **Why deterministic logic matters**

The key idea behind AI Segmentation is not just speed. It is reliability. Every audience is tied to defined behavioral conditions in the data: not a plausible guess about who might belong in a segment, but a queryable group produced from actual shopper behavior and business criteria.

That matters because teams need to trust what they are acting on. A segment has more value when users can understand why it exists, what qualifies a customer for inclusion, and how it can be used in analysis, targeting, or personalization.

## **What makes AI Segmentation different**

Traditional segmentation tools often require users to adapt to the tool. They must navigate dashboards, understand available fields, learn rule builders, and translate a business question into technical steps.

AI Segmentation reverses that workflow. The starting point is the business question itself.

That does not remove the need for structure. It depends on structure. What changes is where the complexity lives. Instead of asking the user to manually translate intent into query logic, the system takes on that translation layer.

AI Segmentation is also connected to business intelligence, not separate from it. The same interaction can be used to answer a question about the business and then turn that answer into a targetable audience. That brings analysis and action closer together.

## **Where AI Segmentation fits in Webscale's architecture**

AI Segmentation is best understood as part of a larger system.

The Webscale CDP is the foundation layer. It captures and structures first-party behavioral data in real time. AI Segmentation is the refinement layer. It turns that structured data into usable audience logic and business insight. The AI Shopping Assistant is the execution layer. It applies structured data and conversational intelligence directly to the storefront experience.

Seen this way, AI Segmentation is not an isolated feature. It is the bridge between captured behavior and downstream action.

## **Why AI Segmentation matters**

Commerce teams are under pressure to act on customer behavior faster and with more precision. At the same time, commerce itself is becoming more conversational, more intent-driven, and more dependent on structured first-party data.

That makes segmentation more important than ever, but it also changes what good segmentation looks like. It is no longer enough for audience creation to be technically possible. It needs to be timely, understandable, and close to the moment where a team can act on it.

AI Segmentation matters because it moves segmentation out of a slow, specialist workflow and turns it into a direct way to translate business intent into operational intelligence.

## **Summary**

AI Segmentation is Webscale's refinement layer for audience intelligence. It uses structured first-party behavioral data from the CDP and makes that data accessible through natural-language interaction. The result is a faster, more direct path from business questions to deterministic audiences and insights that teams can act on.

Two characteristics make that useful in practice. First, segments are dynamic: as shoppers interact with the storefront, segment membership updates automatically against the same behavioral data that defined the audience. There is no manual rebuild required to keep an audience current. Second, because segments are grounded in the same CDP data that continues to capture shopper activity, campaign effectiveness can be tracked against real behavior rather than estimated after the fact. The audience, the campaign, and the measurement all connect back to the same structured foundation.
---
# Valkey persistent
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/valkey-persistent/
Description: Run a Valkey instance backed by persistent storage on a core server.



The persistent service persistently stores its contents to disk at
`/var/lib/valkey`.

## Stack variables

### valkey.version

Default: `8`. The version of Valkey used. This is any valid tag for an
[official image](https://hub.docker.com/r/valkey/valkey).

### valkey.persistent.maxmemory

Default: `100mb`. The Valkey configuration for `maxmemory`.

### valkey.persistent.maxmemory_policy

Default: `allkeys-lru`. The Valkey configuration for `maxmemory-policy`.
---
# Valkey volatile
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/valkey-volatile/
Description: Run a Valkey instance backed by volatile storage on a core server.



## Stack variables

### valkey.version

Default: `8`. The version of Valkey used. This is any valid tag for an
[official image](https://hub.docker.com/r/valkey/valkey).

### valkey.volatile.maxmemory

Default: `1gb`. The Valkey configuration for `maxmemory`.

### valkey.volatile.maxmemory_policy

Default: `volatile-lru`. The Valkey configuration for `maxmemory-policy`.
---
# Vinyl
URL: https://docs.webscale.com/hosting-platforms/hosting-v4/services/vinyl/
Description: Run a [Vinyl Cache](https://vinyl-cache.org/) (fka Varnish) on a core server.



## Stack variables

### vinyl.cache_size

When set, enables a Vinyl cache. This is any value taken for the size of a
Vinyl pool. For example: `1G`.

### Standard vinyl parameters

| Variable                 | Vinyl parameter    | Default  |
|---                       |---                 |---       |
| vinyl.workspace_client   | workspace_client   | 131072   |
| vinyl.workspace_backend  | workspace_backend  | 229376   |
| vinyl.http_resp_size     | http_resp_size     | 131072   |
| vinyl.http_resp_hdr_len  | http_resp_hdr_len  | 131072   |
| vinyl.thread_queue_limit | thread_queue_limit | 100      |