Cloud: Google Cloud, Azure and Alternatives

An Autopilot cluster removes node management, enables the Filestore CSI driver and Workload Identity Federation for GKE by default, and is the closest equivalent of EKS Auto Mode; a Standard cluster keeps node pools under your control and needs the Filestore driver enabled (gcloud container clusters update <cluster> --update-addons=GcpFilestoreCsiDriver=ENABLED). The cluster commands are on GKE Clusters. The PrestaShop-specific point is that PHP-FPM pods need CPU and memory requests equal to what the autoscaler measures against, which Autopilot also requires.

Source: Google Cloud Docs: Create an Autopilot cluster

The image is pushed to europe-west1-docker.pkg.dev/<project-id>/pocketcoffee/prestashop:<git-sha>, and the release workflow changes in two lines: the OIDC step uses google-github-actions/auth with Workload Identity Federation (see Identity and Access) and the cluster login is gcloud container clusters get-credentials. The helm upgrade step is identical.

Cloud SQL runs MySQL 8.4 (the default version at the check date) with a primary and a standby in two zones when --availability-type=REGIONAL, a private address through private services access, point-in-time recovery from the binary log and automatic storage growth. The Auth Proxy is the natural connection for PrestaShop precisely because of the first fact above: the proxy authenticates with the pod’s Google identity, encrypts the traffic itself and listens on a local port, so PrestaShop connects to 127.0.0.1 and never needs a TLS setting.

Source: Google Cloud Docs: gcloud sql instances create

The users are plain MySQL users: give ps_app the privileges PrestaShop needs at runtime and ps_migrate the schema privileges that module and core upgrades need, with SQL GRANT (the lists are on the database page of this section). ENCRYPTED_ONLY is compatible with the proxy, which encrypts on its own; it would reject a direct connection from PrestaShop, which is the reason the proxy is not optional with this setting. If you want a direct connection on the private address, create the instance with --ssl-mode=ALLOW_UNENCRYPTED_AND_ENCRYPTED and accept that the traffic inside the VPC is unencrypted.

The proxy runs as a sidecar. In the Jobs of the chart it has a lifecycle problem: a sidecar that never exits keeps pocketcoffee-migrate, pocketcoffee-install and the cron Job from completing. The remedy is a native sidecar, an init container with restartPolicy: Always, which Kubernetes stops when the main container finishes. The Job below runs the module upgrade command of bin/console against 127.0.0.1:3306; in the chart the same fragment is a conditional block of the pod templates of the web Deployment and the Jobs (the final chart layout is on the Helm page).

Source: Google Cloud Docs: Connect to Cloud SQL from Google Kubernetes Engine

In the Helm values for this cluster the difference is a few lines of the keys defined on the Helm page (secrets.storeName and secrets.valkeyName change in the same way if the store has another name, and shop.cacheEnabled stays false until the cache page’s measurement says otherwise):

Source: Helm Docs: Values Files

The Kubernetes ServiceAccount is bound to roles/cloudsql.client with a principal identifier that names the namespace and the ServiceAccount (the exact binding is on Cloud SQL). One proxy per pod multiplies the connections Cloud SQL sees, so the PHP-FPM pm.max_children times the replicas must stay below the instance’s max_connections: size the ceiling with the autoscaler’s maximum, not its minimum. The legacy mechanism for read replicas (config/db_slave_server.inc.php, described on the database page) has no TLS keys either, so it would need the same proxy per replica; most shops should size the primary instead.

Filestore is a managed NFS server, and the GKE driver exposes it as ReadWriteMany volumes. The built-in classes are zonal-rwx, enterprise-rwx, enterprise-multishare-rwx, standard-rwx and premium-rwx; the Enterprise tier is the one replicated across zones (the site page on Block and File Storage on Google Cloud explains the tiers and the minimum instance sizes, which are large: 1 TiB for the zonal tier at the check date, so verify the minimum for the tier and region you choose). A zonal Filestore is a single-zone dependency under a multi-zone cluster, which is a decision to take knowingly.

Source: Google Cloud Docs: Access Filestore instances with the Filestore CSI driver

The check Pod is a test, not a part of the release: it proves that user 33 (www-data in the official image) can write to the share before the web pods depend on it. The Google documentation recommends fsGroup to manage group ownership of shared volumes and warns that combining fsGroup with the ROOT_SQUASH export option gives an "Access denied" error, and a new instance is owned by root, so create the img/, upload/ and download/ directories once with an admin Pod before the web pods start (the exact list of shared paths is on the shared-files page of this section). The rule of the EFS case applies unchanged: shared files on the volume, never PHP code, and keep var/cache per pod.

Media for shoppers goes through Cloud CDN in front of the global load balancer, with media.pocketcoffee.example as a second host name served by the same backend and set in the media-server settings (see Cloud CDN and Media CDN).

Memorystore for Valkey holds the sessions. It is reached through a Private Service Connect endpoint that a service connection policy creates once per network and region (the commands are on Memorystore and Partner Databases). PHP reads the session settings from the configuration, and the pool file of the chart takes them from the variables VALKEY_HOST, VALKEY_PORT and VALKEY_AUTH; the Memorystore endpoint and credential go into those keys of the secret that the chart’s ExternalSecret reads (secrets.valkeyName). Where the service needs something the pool file does not express (another port, or an authentication that is not a token), generate an ini file from a Secret that holds the endpoint and the credential instead:

Source: phpredis: PHP session handler

The handler needs the redis PHP extension, which is not part of the official PrestaShop image (the image page shows how it is installed). Session locking matters in the back office, where several Ajax requests of one page run at once. Memorystore’s IAM authentication uses short-lived access tokens, and a static auth value cannot follow them: either run the instance with transit encryption and authentication that suits a static password, or put a token refresher in front, and check the authorization modes that gcloud memorystore instances create --help offers on your version. A lost session store only logs people out of the back office and empties carts that were not yet written to the database, so it does not need persistence.

Memorystore for Memcached is deprecated: Google announced that it is no longer a recommended Memorystore service, that new projects cannot create instances after 2027-02-01 and that the service shuts down on 2029-01-31, recommending Memorystore for Valkey instead. PrestaShop’s SQL cache cannot use Valkey, so a new deployment has two honest choices: leave the SQL cache off and give the database a larger buffer pool, or run Memcached on the cluster:

Source: Memcached project wiki

The headless Service name resolves to the pod addresses, which you enter as servers in Advanced Parameters > Performance > Caching (or as rows of ps_memcached_servers) with the caching system CacheMemcached. PrestaShop’s server list is a static table of addresses and weights, so it does not follow pods that are replaced: use a fixed set of replicas behind a StatefulSet with stable names if you go this way, or accept that a rescheduled pod changes an address and the table needs updating. The cache holds disposable data, so losing a node only costs a few slow requests. Pin the image by digest in your own registry, as for every image in this section.

Secrets come from Secret Manager. The External Secrets Operator reads them with a store that authenticates through Workload Identity, and the chart’s ExternalSecret is unchanged except for the store name and the remote keys (the store manifest is on the WordPress page of this section; the keys are PS_COOKIE_KEY, PS_COOKIE_IV, PS_NEW_COOKIE_KEY and PS_SECRET of PrestaShop, and the credentials of the two database users in their own secrets, as on AWS). The GKE add-on for Secret Manager mounts secrets as files instead (see Secret Manager and Cloud KMS).

The HTTP entry is a Gateway of class gke-l7-global-external-managed, with the certificate for www.pocketcoffee.example in Certificate Manager and Cloud Armor attached to the backend (see Load Balancing and Cloud Armor). The Gateway, HTTPRoute and HealthCheckPolicy objects are the ones of the WordPress page, with this PrestaShop difference: the load balancer’s probe sends a request to the pod without the shop’s host name, and PrestaShop redirects requests whose host differs from the one in ps_shop_url to the shop domain, so a probe on / can see a redirect and mark the backend unhealthy. Point the health check at the static location that the nginx configuration of the container image page answers with a plain 200. The back office stays at /admin-pocketcoffee/ and is restricted at the gateway or with Cloud Armor (see Security).

Azure Managed Redis is the current first-party service (Azure Cache for Redis is retiring in two waves, on 2027-03-31 for the Enterprise tiers and 2028-09-30 for Basic, Standard and Premium). It speaks the Redis protocol, so the session ini file of the Google Cloud section applies with the endpoint’s host and port. It is not Valkey, and its endpoint listens on port 10000 with TLS, so the port is not 6379. The clustering policy is fixed at creation (OSSCluster needs a cluster-aware client; EnterpriseCluster lets a client that does not follow cluster redirects connect to a single endpoint, which is the simpler fit for session storage), and a new cache defaults to Microsoft Entra authentication with access keys off, so enable access keys on a cache reachable only from the cluster’s private network, or run a token refresher. The commands and the choices are on Redis and Partner Databases on Azure.

The Azure pages of this site list no managed Memcached service, so verify the current Azure offer before relying on that statement; if there is none, the SQL cache has the same two choices as on GKE: off, or the Memcached manifest of the Google Cloud section on the cluster (the manifest is portable). Do not use APCu for the SQL cache across several pods.

Azure Files is the shared file system. It offers two protocols, and the choice has consequences for PrestaShop, which writes thumbnails and uploads as many small files:

Source: Microsoft Learn: Create and use a volume with Azure Files in AKS

For img/, upload/ and download/ use NFS unless the organisation forbids unencrypted traffic inside the virtual network, in which case use SMB with explicit ownership. The two storage classes:

Source: Microsoft Learn: Create and use a volume with Azure Files in AKS

Use one class or the other, not both; they are shown together so the differences are visible. Retain keeps the share when the claim is deleted, which is what you want for product images. The NFS share’s reachability is the virtual network’s, so the node subnet must be allowed by the storage account’s network rules, and the PHP code never goes on the share, as on every cloud.

On AKS the ServiceAccount carries the identity of a user-assigned managed identity through a federated credential: the ServiceAccount has the annotation azure.workload.identity/client-id and the pod template the label azure.workload.identity/use: "true", and the identity needs the role Key Vault Secrets User on the vault (see Key Vault and Secrets and Identity and Access; the store manifest for the External Secrets Operator is on the WordPress page of this section). The HTTP entry is the application routing add-on’s Gateway API implementation, or Application Gateway for Containers with the Web Application Firewall, and Azure Front Door is the edge for media.pocketcoffee.example (see AKS Microservices, Gateways and Load Balancing and Front Door and CDN). The older managed NGINX mode rests on the retired ingress-nginx upstream, so none of the manifests of this section use it. The host-name redirect of the Google Cloud section applies to the health probe on Azure too.

A task definition replaces the Deployment: nginx and PHP-FPM are two containers of one task and share localhost, an ALB target group replaces the Service and an ECS service with target-tracking scaling replaces the HPA (see ECS and Fargate and ECS Deployments, Scaling and Networking). What changes for PrestaShop: the shared paths are an EFS volume declared in the task definition (Fargate supports EFS) with an access point that fixes UID and GID 33; the secrets come from Secrets Manager through the task definition; there is no Helm, so the release is a new task definition revision, the pocketcoffee-migrate step is a one-off run-task of the same image before the service update, and the cron of pocketcoffee-cron is an EventBridge Scheduler rule that runs the task with the cron command.

Source: Amazon ECS Developer Guide: Task definition parameters

The variable names in the environment and secrets entries are those that the parameters.php of the Helm page reads, and the secret names are those of the Secrets Manager secrets of the Helm page; the mount path is an illustration: use the layout of the production image, where img/, upload/ and download/ are links into the shared mount. The excerpt shows two of the secrets; PS_COOKIE_IV, PS_SECRET and the others follow the same pattern. The nginx container needs the static files of the shop (theme and module assets) at the paths it serves, so build its image from the stage of the Dockerfile that holds the code. Fargate gives each task ephemeral storage and no persistent disk, which is the right default for var/cache (see the cache page of this section for the warm-up at build); only the shared paths go on EFS. On ECS the database and cache endpoints are the same RDS and ElastiCache of the reference architecture, so the database page applies unchanged, including the TLS question.

The oldest pattern: an AMI baked with Packer (or a launch template that pulls the container image), an Auto Scaling group over three zones behind an ALB, RDS, ElastiCache, EFS, and a rolling instance refresh as the release (see EC2 and Auto Scaling). It has the fewest moving parts and the highest operating burden. For PrestaShop, each instance is a small version of the old single server, and these are the places where that bites:

Source: Amazon EFS User Guide: Mounting with the EFS mount helper

The file system and access point identifiers are placeholders. This script replaces the packaged img/ directory of the AMI with a link, so the baked image must not contain files that exist nowhere else (the demo images of a fresh install, for example). The rest of the infrastructure is the OpenTofu of the Helm page without the cluster module, with an aws_autoscaling_group over the launch template (see the Auto Scaling resource in the OpenTofu registry).

Cloud Run runs a container without a cluster: requests go to instances that scale between a minimum and a maximum, each serving a configurable number of concurrent requests (see Cloud Run). PrestaShop fits if every piece of state is external, and three details of its source decide how:

Source: Google Cloud Docs: Cloud Run YAML reference

Deploy it with gcloud run services replace service.yaml --region=europe-west1, and run the migration and the cron as Cloud Run Jobs of the same image (gcloud run jobs create) triggered by Cloud Scheduler. The annotations and the volume syntax are composed from the reference above and have not been run; check them with the current reference. Limits to weigh: the request timeout (not a problem for page views, but long imports and thumbnail regenerations belong in Jobs), cold starts of a PHP application (minimum instances address them), and no persistent disk.

Container Apps is the Azure analogue: an environment with a virtual network, revisions per deployment, HTTP scaling rules, Key Vault references for secrets, multiple containers per revision, and jobs for scheduled and manual work (see Container Apps and Container Apps: Scaling, Jobs and Dapr). What changes for PrestaShop is the shared file system, whose rules are stricter than on AKS:

Source: Microsoft Learn: Use storage mounts in Azure Container Apps

The database has the TLS question of the AKS section, without a proxy option inside Container Apps other than a second container in the same revision, so the choices are the server setting or a sidecar you operate. Sessions use Azure Managed Redis as on AKS; there is no SQL cache without a Memcached you run yourself. The migration and the cron are Container Apps jobs of the same image (a manual job for pocketcoffee-migrate before the revision switch and a scheduled job for pocketcoffee-cron), and the secrets are Key Vault references (see the Container Apps page above).

A managed host removes the infrastructure and sells PrestaShop as a service. The PrestaShop project itself describes several kinds of offer on prestashop.com (a hosted offer with the shop pre-installed, a managed PrestaShop hosting platform, and partner hosting companies), and the list, the plans and the partners change, so verify the current offers on prestashop.com/hosting and in each provider’s documentation before deciding. The questions that decide the choice are the same as for any managed platform:

When the answers are acceptable and nothing needs custom infrastructure (private networking to internal systems, custom nginx rules, a compliance regime), a managed host is the cheapest operation. The self-hosted requirements are on Installation and Local Environments, and the hardening you would otherwise do yourself is on Security.