Learn how to deploy, scale, and optimize Shopware on Platform.sh PaaS with this ultimate guide. We cover architecture, setup, config files, performance tips, benchmarks, comparisons, and best practices for secure, high-performance Shopware hosting.
Shopware’s Platform-as-a-Service (PaaS) offering lets merchants and developers run Shopware stores in the cloud without managing servers. In fact, Shopware PaaS is powered by Platform.sh. Platform.sh provides a container-based, Git-driven PaaS that automates deployment, scaling, and infrastructure management. The result is “full flexibility and code ownership” of a self-hosted Shopware project, with the complexity of infrastructure and CI/CD handled for you. In this guide, we’ll deep-dive into Shopware on Platform.sh, covering technical setup, configuration, performance, security, real-world use cases, and comparisons to alternative hosting approaches
Shopware PaaS is Shopware’s cloud hosting solution built on Platform.sh. It is designed for merchants who have development teams and want full control of their Shopware environment without the DevOps overhead. In simple terms, Platform.sh is a full-stack PaaS: it provisions environments, manages the infrastructure, and runs Shopware code. Every Git branch can become its own live environment, complete with a unique URL and SSL certificate. Developers push code, and Platform.sh automatically builds, deploys, and runs Shopware, including running database migrations and asset builds as needed.
Shopware PaaS is a cloud e-commerce platform that “enables your organization to iterate, deploy, and develop your strategy in the fastest, most scalable, and most secure way.” It offers turnkey infrastructure (databases, caching, files, etc.) so developers can focus on code. As a Shopware sales overview explains, PaaS brings dev teams full access to code and data while offloading infrastructure maintenance to the platform.
Shopware distinguishes its PaaS from SaaS (Shopware Cloud): PaaS gives customizability and control, while SaaS offers fully managed, no-ops hosting. In comparison terms:
In fact, Shopware claims PaaS users achieve “5× faster development” compared to self-hosting. It promotes features like auto-scaling, multiple preview environments, and integrated monitoring that dramatically reduce manual DevOps work (one success story even cites “90% less DevOps”). We’ll unpack below.
Every branch/pull-request is a full clone of the site (code and database), with HTTPS and SSL automated. Teams can spin up throwaway dev/staging environments instantly. This GitOps model accelerates collaboration and QA: “Simultaneously test different iterations across separate environments through 5× faster development”.
Standard services include MySQL/MariaDB, Redis, RabbitMQ, Elasticsearch, networked file storage (for media), and more. You declare these in .platform/services.yaml. For example, one sample config defines a MySQL service and a network-storage volume for media files. Platform.sh also provides add-ons (Memcached, Mailhog, APM, etc.) via configuration. All services are provisioned and managed by the platform.
Production environments can auto-scale on demand and run on globally distributed infrastructure. Platform.sh offers enterprise SLAs (99.9–99.99% uptime for Enterprise plans) and can handle traffic spikes automatically. For example, Platform.sh can double environment resources to absorb seasonal peaks. That means your Shopware site stays responsive during Black Friday or holiday surges without manual intervention.
Deployments happen on every Git push. Platform.sh has a configurable build/deploy pipeline (via .platform.app.yaml hooks) that runs Composer, asset builds, migrations, etc. without custom scripts. For instance, a typical build hook might install Shopware assets, dump bundles, and compile the storefront. After build, a deploy hook can run database migrations and plugin refreshes, as shown in one example configuration. The result: minimal downtime deploys and instant rollbacks. Platform.sh’s Git-based workflow means releasing new features or fixes is as easy as pushing a Git branch, with the platform handling the plumbing.
Platform.sh provisions modern PHP (8.x) and HTTP runtimes (Nginx), plus Varnish full-page caching and Redis. Environments can include Fastly CDN, Elasticsearch, and RabbitMQ for asynchronous tasks. Shopware’s docs note each PaaS project includes Blackfire profiling out of the box to monitor performance. Using these tools, developers can analyze and optimize response times under real load. In practice, Shopware PaaS sites report “seamless scaling and outstanding performance”.
TLS certificates are auto-provisioned by Let’s Encrypt for every environment’s URL. Platform.sh supports Web Application Firewalls (their own WAF or Fastly’s) and isolates projects per account. Enterprise plans include SSO, audit logs, and compliance features (PCI, SOC2, etc.).
Platform.sh is not tied to one IaaS. It runs on its own managed cloud but lets you choose regions or even bring-your-own-cloud. The Shopware site emphasizes that you can “choose your preferred cloud provider for seamless operations regardless of provider”, avoiding vendor lock-in.
In summary, Platform.sh turns Shopware hosting into a predictable, managed platform, freeing you from low-level concerns. As one agency noted, PaaS provides “complete control with flexibility and scalability at the same time,” reducing DevOps burdens and speeding development.
Platform.sh environments are structured as multiple containers. Each environment always has a router container (handling incoming HTTP) and one or more app containers (running PHP/Shopware). Additional service containers provide MySQL/MariaDB, Redis, Elasticsearch, RabbitMQ, etc. Developers can also define worker containers for background jobs or cron tasks. In this architecture, a router forwards requests to a Shopware app container, which talks to a MySQL database and, say, a Redis cache or Elasticsearch service. A worker container (for example, running RabbitMQ consumers) can independently access the database. All inter-container connections and environment variables are managed by Platform.sh. This architecture ensures each piece (web, DB, cache, workers) is isolated and restartable independently, boosting resilience and performance.
First, get access to Shopware PaaS (often via your Shopware partner or sales team). Then install the Shopware PaaS CLI (a wrapper around the Platform.sh CLI). Authenticate it with your account (e.g. shopware auth ). You’ll need your PaaS project ID, which identifies your Shopware project environment.
composer create-project shopware/production
composer require shopware/paas
git init
git add .
git commit -m "Initial Shopware project"shopware project:set-remote <PROJECT_ID>.platform/routes.yaml
: Routes incoming traffic.platform/services.yaml
: Defines MySQL and file storage.platform.app.yaml
: App setup, hooks, environment variablesgit push shopware masterbin/console doctrine:migrations:migrate --all -nReal examples show sub-second page load times under load.
Adopted Shopware PaaS for improved performance, security, and automated scaling, ensuring smooth customer experiences.
| Aspect | Platform.sh PaaS | Self-Hosted VPS | Shopware SaaS |
|---|---|---|---|
| Infrastructure | Managed, scalable, CDN | Manual server management | Managed by Shopware |
| Customization | Full control | Full control | Limited |
| Deployment | CI/CD with Git | Manual or custom | One canonical environment |
| Performance | Auto-scaling, Redis, CDN | Manual scaling | Cloud scaling |
| Maintenance | Platform-managed | User-managed | Shopware-managed |
| Cost | Predictable subscription | Varied costs | Fixed per store |
| Ideal for | Teams needing flexibility | Tech-savvy small teams | New merchants |
Shopware PaaS on Platform.sh combines flexibility, speed, and enterprise reliability. It allows developers to focus on building great customer experiences while automating deployment, scaling, and infrastructure management. Use this guide and best practices to unlock the full potential of Shopware in the cloud.
Official Shopware and Platform.sh documentation and success stories from solution25.