Magento 2 on Kubernetes: k3s and OpenTofu

Magento 2 on Kubernetes runs six storefront groups for one of our clients. Each production AWS account holds a single k3s node. OpenTofu builds the AWS account and deploys the Magento app from the same code. All six groups share one layout across four production accounts. Only Cloudflare can reach the web ports, and the network has no NAT gateway to pay for.

The client

The client sells furniture online through regional Magento 2 storefronts. The storefronts form six groups in four production AWS accounts. The UK group serves two countries. All six groups run the same layout, and all of them shipped releases in September 2026.

The same layout is behind the bill cut in our AWS Savings Plans case study. There, one store’s AWS bill fell from $291.75 to $178.53 a month before tax.

What the client needed

• Infrastructure the client owns. The code and the AWS accounts belong to the client.
• One layout for every store. A new storefront group gets the same setup as the others.
• A small bill. Each store pays for one node and a managed database.
• A short path to production. A git tag starts every release.

Next to Adobe Commerce Cloud

Adobe Commerce on cloud infrastructure scales too. On Pro projects Adobe resizes a node when memory pressure crosses a threshold that Adobe sets. Adding web nodes is horizontal auto scaling, and it exists only on the Scaled architecture. Adobe turns both on through a support ticket, after load testing on staging. Adobe sets the limits from each merchant’s contracted resources, as its auto scaling docs explain.

With Adobe you rent capacity sized by your contract and change it through support. Here the client owns the infrastructure code and runs it on its own AWS account. A larger node or a new account is a change to that code.

The architecture

OpenTofu builds each AWS account

OpenTofu provisions the VPC, the EC2 node, an Elastic IP, RDS MariaDB, the ECR registry and Secrets Manager. The database keeps 30 days of backups. GitLab signs in to AWS through OIDC.

The node runs on AWS Graviton (arm64). It boots from a machine image that Packer builds with k3s already installed. Ansible then sets up the cluster with Helm, cert-manager and the New Relic monitoring bundle.

We use OpenTofu because it is the open-source fork of Terraform and it works.

OpenTofu also deploys Magento

The Magento app is plain Kubernetes manifests in OpenTofu, with no Helm charts. The same code sets up the New Relic alerts and synthetic monitors. OpenTofu keeps its state in S3 and locks it with S3’s native lockfile.

Inside the cluster:

• One pod runs php-fpm, nginx, Varnish 7.5, cron and a Redis cache.
• StatefulSets run Redis for sessions, RabbitMQ and OpenSearch.
• Traefik routes the traffic, with one cert-manager certificate per store.
• A cache-warmer job runs after each deploy.
• Media comes from S3, with CloudFront in front for the UK.

The media setup has its own write-up in Magento 2 CDN on AWS.

Cloudflare in front, no NAT gateway

The node’s security group accepts ports 80 and 443 only from Cloudflare’s IP ranges. Every visitor reaches the store through Cloudflare.

The VPC has no NAT gateway. A NAT gateway bills by the hour and by the gigabyte. That is expensive at this scale.

A staging account that sleeps

Staging runs in a separate AWS account. Its EC2 node and database stop every night. CI jobs start them again when the team needs staging.

From git tag to production

1. A git tag in the shop repo starts the build.
2. AWS CodeBuild builds an arm64 image and pushes it to Amazon ECR. CodeBuild also acts as the GitLab runner.
3. A commit bumps the image tag in the OpenTofu variables.
4. On master, tofu apply reaches the cluster through the GitLab agent for Kubernetes.
5. The deployment does a rolling update, and the cache warmer runs.

To roll back, the team reverts the image tag bump from step 3.

How the fleet grew

• August 2024: a prototype of the layout.
• September 2024: one infrastructure monorepo.
• February 2025: the first storefront groups went live on k3s.
• May 2025: one repo per AWS account.
• September 2025: the UK group went live.

The result

• Six storefront groups on one layout. Four production accounts run the same code.
• The client owns its cloud. The infrastructure code and the AWS accounts are the client’s.
• Releases start from a git tag. A rollback reverts the image tag bump.
• A smaller AWS bill. For one store the bill fell 38.8%, as the Savings Plans case study shows.
• Staging sleeps at night. Its node and database stop until CI starts them.

Run your store on infrastructure you own

We build the same layout for other Magento 2 stores on AWS. To talk about yours, tell us about your store.