Which way to run Shopware fits your team in Shopware SaaS vs PaaS vs self-hosted
Vendor-managed options trade control for managed operations, while self-hosting trades operating work for control. The hosting model decides who patches, upgrades and recovers the shop, and that answer matters more than the license. Shopware's code is MIT-licensed, so the license permits you to run it yourself, but it does not decide who runs it. Shopware states that it can run as SaaS, as PaaS on managed infrastructure or self-hosted, and the pricing page ties plan cost to gross merchandise value and other individual factors. Ask for the exact hosting-to-plan mapping in writing before you compare totals.
Choose SaaS when your team has no in-house platform engineers, your data can sit in the vendor's hosting regions, and your customization needs stay within what the vendor's platform allows. Choose PaaS on managed infrastructure when you need some control over the stack, such as particular extensions or integration points, but do not want to run servers. Choose self-hosting when a regulator, customer contract or internal policy requires a specific data location, when you need custom infrastructure, or when you already run containers, databases and patch pipelines well. Self-hosting shifts cost to your payroll, hosting bill and change process, so check your own staffing before committing.
Before you decide, confirm three things with Shopware and your own architects: which data residency options each hosting model offers, which upgrade path applies when you move between the two maintained minor lines (6.7 and 6.6 were both released on October 7, 2026), and who is responsible for security patches and backups under each contract. If you self-host, DeployOpen can plan, harden and document that stack inside your own cloud account or data center, but the scope, deliverables and timeline are agreed in writing before work starts.
How self-hosted and vendor cloud compare on the factors that decide the choice
This table sets Shopware's license, plan pricing, editions, hosting models, support response times and customization freedom side by side. Read each row for the condition under which the self-hosted or vendor-run side wins, and treat every cell marked for confirmation as a question to put to Shopware before you commit.
| Factor | Self-hosted Community Edition | Paid plans (Rise, Evolve, Beyond) |
|---|---|---|
| License | MIT License for the Shopware code. Self-hosting the code carries no license fee of its own. | Paid plans are commercial subscriptions on top of the MIT-licensed code. Confirm the terms of each plan with Shopware. |
| Plan pricing basis | No subscription. Shops above 1 million euros in annual GMV must move to a paid plan. | Rise at 600 euros per month, Evolve at 2,400 euros per month, Beyond at custom pricing. Pricing also reflects GMV and other factors. |
| Editions available | Community Edition with visual page builder, product management and Shopware Payments. | Rise, Evolve and Beyond. Evolve adds B2B quotes and approvals. Confirm the full feature list per plan. |
| Hosting models offered | Self-hosted on servers you choose. Confirm supported infrastructure locations with Shopware. | SaaS, PaaS on managed infrastructure, or self-hosted. Confirm which hosting regions each option offers. |
| Support response by plan | Community support only. | Rise 8-hour response, Evolve 4-hour response, Beyond 1-hour response with 24/7 support. |
| Customization freedom | Full control of code and extensions, limited by your own team's capacity to maintain them. | Confirm with Shopware which code changes, extensions and server settings are allowed on SaaS and PaaS. |
| Backup and operations | Your team or partner owns backups, patching and upgrades between the 6.6 and 6.7 minor lines. | Confirm with Shopware which backup, patching and upgrade tasks it performs on each hosting model. |
What hosting choice changes for data location, access and compliance evidence
Moving Shopware between SaaS, PaaS and self-hosting changes who controls data location, administrative access, logs and incident response. Each card names one of those shifts and the question to settle before choosing a model. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit report or certification.
Data location and residency
Under SaaS or PaaS, the physical location of the shop database, media files and backups is set by the provider's hosting arrangements, not by you. Under self-hosting, you choose the region, data center or air-gapped network and document it. Ask Shopware in writing which regions host your data, where backups and support copies sit, and whether any sub-processors receive personal data. Confirm these answers against your own data protection requirements before signing.
Administrative access
Hosted models give the provider's operations staff administrative control of the underlying servers, while you control the shop admin accounts. Self-hosting means your team holds root, database and deployment access, so you must define who can reach the server, the database and the Shopware admin, and how that access is approved and removed. Document these roles so an assessor can trace each privileged action to a named person.
Logging and audit evidence
Under self-hosting, web server, PHP, database and Shopware admin logs live in your infrastructure, so you must decide retention, storage and tamper protection yourself. Under SaaS or PaaS, ask what access logs the provider keeps, how long they retain them, and whether you can export them on request. Without exportable logs for admin changes, payment configuration and plugin installs, you may be unable to show an assessor who changed what.
Incident responsibility
Each model splits incident work differently. A provider may detect and contain infrastructure incidents, but you still need to know how it notifies you, within what window, and what it will hand over for forensics. Under self-hosting, detection, containment, notification and recovery all sit with your team or your implementation partner. Write the split into a responsibility matrix before go-live so no step is assumed to belong to someone else.
Control ownership for compliance evidence
Assessors review each control against the party that operates it. For a self-hosted Shopware shop, you must evidence patching, backup restore tests, access reviews, change records and vulnerability management yourself. For SaaS or PaaS, the provider may supply some evidence, but you still own the controls around your configuration and plugins. Ask the provider which reports or attestations it can share and which of your controls remain yours, and confirm that independent auditors accept them.
How assessors review each model
Assessors will ask who operates each system, where the evidence lives and whether the shared responsibility split is written down. Self-hosting gives you direct evidence but more of it to produce, and a DeployOpen engagement can prepare systems, controls and documentation for that review. DeployOpen does not issue audit reports, attestations or certifications, so the assessment outcome comes from the independent auditor or certification body you engage.
What your team runs in each model and what it hands to the vendor
This table shows who typically operates each task under Shopware SaaS, PaaS on managed infrastructure and self-hosting. Where the supplied information does not settle a split, the cell tells you to confirm it with Shopware in writing. Self-hosting moves every row to your team or a service provider, so read the self-hosted column as the full operating workload.
| Operating task | SaaS | PaaS on managed infrastructure | Self-hosted |
|---|---|---|---|
| Server provisioning | Shopware runs the servers; confirm the split in your contract. | Hosting provider sets up infrastructure; confirm which layers Shopware manages. | Your team or provider sizes, builds and maintains servers, networks and storage. |
| PHP and database runtime | Shopware selects and maintains the runtime; confirm versions and change notice. | Confirm whether PHP and database versions are set by the host or by you. | Your team selects PHP and database versions that match the Shopware release and patches them. |
| Shopware version upgrades | Shopware schedules upgrades; confirm timing, test windows and any opt-out. | Confirm who applies upgrades and who tests extensions before go-live. | Your team or provider plans and tests moves between the 6.6 and 6.7 minor lines. |
| Security patching | Shopware patches the platform; confirm response times for critical fixes. | Patching is often shared between host and vendor; confirm each layer in writing. | Your team applies OS, PHP, database and Shopware patches on its own schedule. |
| Backups and restore tests | Confirm backup frequency, retention and whether restore tests are included. | Confirm whether the host backs up database and files and who runs restore tests. | Your team designs backups, keeps copies off-host and runs restore tests regularly. |
| Scaling and performance | Confirm how capacity is added and which limits apply to your plan. | Scaling depends on the host; confirm what you can configure yourself. | Your team or provider sizes servers, caching and database capacity and load tests. |
| Extensions and theme deployment | Confirm which extensions are allowed and who deploys and tests them. | Your team usually deploys extensions and themes; confirm any platform checks. | Your team owns code deployment, compatibility testing and rollback. |
| Monitoring and incident response | Confirm uptime monitoring, incident notice and support response times in the contract. | Host monitors infrastructure; your team handles application alerts unless agreed. | Your team or provider runs monitoring, on-call rotation and incident handling end to end. |
How plan pricing and hosting costs add up across the three models
The software fee is only one line in the total cost of running Shopware, and it is the one line that is easiest to read off a list. Shopware's Community Edition carries no license fee under the MIT License. The paid plans are priced on gross merchandise value and other individual factors: Rise at 600 euros per month, Evolve at 2,400 euros per month, and Beyond at custom pricing, according to Shopware's pricing page. Shopware says the plan price is based on GMV and further individual factors, so the published figure is a starting point rather than the amount you will pay. Once a shop passes 1 million euros in annual GMV, the paid plan is no longer optional. Hosting, implementation and extension work sit alongside that fee in every model. In SaaS, Shopware's plan covers much of the infrastructure. In PaaS and self-hosted deployments, you pay the hosting provider or your own data center team directly, and the infrastructure bill grows with traffic, storage and the number of environments you keep for staging and testing.
Some costs are one-time and some recur. Discovery, the initial build, data migration, theme and extension work, and security hardening are typically one-time, and in a fixed-scope engagement they are priced from the written scope. Recurring costs include the plan fee, hosting, backups, monitoring, third-party extension licenses, and the people who apply Shopware's maintained minor line upgrades, which currently means tracking both 6.7 and 6.6 releases. Support tiers recur too: Rise lists an 8-hour support response, Evolve 4 hours, and Beyond 1 hour, 24/7. Faster response is a cost driver, as are B2B quotes and approval workflows, which add configuration and testing effort. Ask each provider for a line-item quote that separates the plan fee, hosting, one-time implementation, extension and integration work, upgrade effort per minor line, and any retainer. For DeployOpen, the quote follows from the written scope and DeployOpen does not publish prices. For Shopware, ask which factors set your plan price, whether GMV is measured over the preceding 365 days, and which support response times and approval features the quoted tier includes.
Which features and extension options each hosting model keeps
Under SaaS, Shopware operates the hosted shop, so your options depend on the plan and on what the hosted service allows. The free Community Edition includes a visual page builder, product management and Shopware Payments, but Shopware Payments comes with community support only. Paid plans add service levels and business features, and the Shopware pricing page lists them by tier.
- Community Edition scope: The visual page builder, product management and Shopware Payments are listed for the free edition. Confirm whether the Community Edition is offered on SaaS hosting at all, since the supplied information does not state it.
- Rise: Listed at 600 euros per month with AI-assisted content and an 8-hour support response.
- Evolve: Listed at 2,400 euros per month with B2B quotes and approvals and a 4-hour support response.
- Beyond: Custom pricing with 1-hour, 24/7 support. Ask for the scope of this tier in writing.
- Code and server access: The supplied information does not say whether custom plugins, server-level changes, database or file system access, scheduled jobs or third-party integrations are possible on a hosted plan. Ask Shopware directly for each item.
Before you sign, ask Shopware in writing which extension points the plan you are quoting includes and how the GMV-based price applies to your shop.
On PaaS, Shopware runs on managed infrastructure, which usually means part of the operating work moves to the provider and part stays with your team. The feature set still follows the plan you choose. The Community Edition features, which include the visual page builder, product management and Shopware Payments with community support only, are the baseline. Plan-level features are priced on gross merchandise value and other individual factors, so the quote depends on the shop profile.
- Plan features: Rise, Evolve and Beyond add the features and support levels described on the pricing page. Match each feature to a documented business need before you choose a tier.
- Custom plugins: Confirm whether you can install and maintain your own plugins on the managed platform, and who reviews them during upgrades.
- Server-level changes: Confirm which server settings, PHP extensions or background services you can change, and which the provider controls.
- Database and file system: Confirm whether you receive direct database access, file system access or both, and how backups and restores are handled.
- Scheduled jobs and integrations: Confirm whether you can define scheduled jobs and connect third-party systems such as ERP, payment or shipping services, and whether those connections need provider approval.
Ask the provider for a written list of these permissions for the plan you are considering, because they decide how much custom work your team can carry out without a change request.
When you self-host, you run Shopware on your own servers or cloud accounts, and the feature set is the Community Edition plus whatever you build or buy. Shopware is licensed under the MIT License, which allows you to modify the code you run. The MIT license file in the shopware/shopware repository is the place to confirm the terms that apply to your copy. Community Edition features, including the visual page builder, product management and Shopware Payments, remain community-supported in this model.
- Code changes: The MIT License permits modifications to the code. Your team carries the work of applying them and keeping them compatible with upgrades.
- Server and database access: You control the database, file system, PHP configuration and server-level settings, along with the backups and monitoring for them.
- Scheduled jobs and integrations: You define scheduled jobs and third-party connections, and you own their failure handling and credentials.
- Maintained lines: Shopware 6.7.15.1 and 6.6.10.29 were both released on October 7, 2026, so two minor lines are maintained. Plan which line you run and when you move between them.
- Revenue threshold: Shops over 1 million euros in GMV over the preceding 365 days must move to a paid plan under the Fair Usage Policy, even when self-hosted. Confirm how this applies to your shop.
Before you choose this model, confirm with your implementation partner and Shopware which customizations your team can own over several upgrade cycles.
How the two maintained Shopware lines change upgrade timing in each model
The two maintained minor lines matter most when you decide who picks the upgrade date. Shopware 6.7.15.1 and 6.6.10.29 were both released on October 7, 2026, which shows that the project is shipping fixes on two lines at once. A self-hosted team can choose which line to run and when to move between them, so the calendar is set by its own change board, test windows and release freeze dates. The cost of that control is that your team or your implementation partner plans the move, rebuilds the test environment, checks custom plugins and themes against the new line, and rolls back if something breaks. Under a PaaS arrangement on managed infrastructure, the operator often owns the platform layer (servers, database, patching of the host), but the shop application version is still a decision you need to confirm in writing. Ask whether the provider upgrades the application on its schedule or waits for your approval, and who runs the regression tests.
In a vendor-operated SaaS model, the timing is usually set by the vendor. Before you commit, confirm which Shopware lines each hosting option supports, whether you can stay on the older line for a defined period, and whether custom extensions are allowed on the platform at all. Ask for the lifecycle policy for each line in writing, including the date each one stops receiving fixes. The supplied facts do not give end-of-support dates for either Shopware line, so do not plan a migration window from assumptions. A practical check is to write down, for each hosting option, the latest line it will run, the earliest date it will move you forward, and the notice period you get before a forced change. Compare those answers with your own freeze calendar, peak trading periods and the length of your regression suite.
Questions buyers ask before choosing a Shopware hosting model
How much does a self-hosted Shopware setup cost to run?
Self-hosting moves cost from a vendor subscription into your own infrastructure and people. The main components are the servers or cloud accounts that run the shop, the database, caching and search services, storage and backups, monitoring, staging environments, and the staff or partner time to patch and upgrade. Shopware's free Community Edition is MIT-licensed, so the software license itself carries no fee, but a paid plan may apply once annual gross merchandise value passes the threshold. Costs recur monthly for hosting and staffing and rise with traffic, catalog size, number of environments and the frequency of upgrades. Ask any provider for a written quote that separates one-time setup from recurring hosting, support and maintenance, and state which Shopware minor line it targets.
How long does a Shopware migration to a new hosting model take?
The duration depends on the size and complexity of the shop, not on the hosting label alone. The main drivers are the volume of products, customers and orders to move, the number of custom plugins and integrations (payment, ERP, shipping, tax), the amount of theme work, the number of environments to rebuild, and the testing scope agreed before cutover. Migrations between SaaS, PaaS and self-hosted setups also depend on what data and configuration the current host lets you export. Ask for a written plan with a named scope, deliverables, a test and rollback approach, and a timeline that lists assumptions. Treat any duration you hear without that breakdown as unverified.
Can our team run self-hosted Shopware without outside help?
Yes, many teams do, but running a self-hosted shop means owning skills that a SaaS plan hands to the vendor. Your staff need to manage PHP and the web server, the database, search and cache services, deployments, Shopware upgrades between minor lines, plugin compatibility testing, security patching, backups with tested restores, and incident response. Check the current Shopware system requirements and the supported versions in its release notes before you commit. Ask yourself whether you have on-call coverage and a documented runbook. If those gaps exist, request a written support scope from a partner that covers operations, not only the initial build.
Does the 1 million euro GMV rule apply differently to self-hosted installs?
Shopware's pricing page says that shops linked to an account generating more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. The page describes this as a Fair Usage Policy tied to the account, so the hosting model alone should not change the rule, but you should not assume it. Confirm in writing with Shopware how the rule applies to self-hosted, PaaS and SaaS deployments, how GMV is measured for multi-shop or multi-account setups, and what happens if you cross the threshold mid-year. Keep the answer and its date in your procurement file.
Do SaaS or PaaS hosting limit Shopware customization?
They can. Hosted options usually restrict server access, custom PHP extensions, background worker configuration, the file system, outbound network rules and which plugins or code can be deployed. Self-hosting removes most of those limits but gives you the full maintenance load. Before you choose, list the customizations your business needs, such as custom checkout logic, ERP connectors, deep integrations or custom data flows, and ask the vendor in writing which of them are supported on each hosting tier, which plugins are allowed, how custom code is deployed and reviewed, and how upgrades affect your changes. Get the answers tied to the Shopware plan you intend to buy.
When do DeployOpen's fixed-scope work or retainers make sense for Shopware?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. A fixed-scope engagement suits a team that knows what it needs built or migrated, such as an initial self-hosted deployment, a migration off an existing host or a hardening and documentation pass, with scope, deliverables and timelines agreed in writing before work starts. A retainer suits teams that want ongoing upgrades, support and continuous testing after go-live. If your team can already operate Shopware, you may need only a one-off review. DeployOpen does not publish a price list, so a quote follows from the written scope.
How to move Shopware between SaaS, PaaS and self-hosting without losing data
This sequence gives you a verified copy of your shop on the target environment, with orders, customers, media and integrations checked before any traffic moves. It also leaves the source intact long enough to roll back if the cutover goes wrong.
Inventory the current hosting contract and data
Before anything moves, list what you run today: the hosting agreement and its exit terms, the Shopware line and patch level, PHP and database versions, installed extensions and custom code, storage for media and documents, and every system that reads from or writes to the shop, including ERP, payment, shipping and marketing tools. Record who holds admin access and where backups are kept. Confirm with your current host whether they will provide a full database and file export and how long they keep backups after termination. The step is done when you have a written inventory signed off by the shop owner and the operator.
Confirm export and import paths with Shopware
Ask Shopware, or the partner operating your SaaS or PaaS plan, which export and import paths are supported for your plan and line. The researched facts for this page do not include vendor migration tooling, so do not assume one exists. Ask whether data can be exported in a documented format, whether customer and order records can be moved with their history, and whether media and theme assets come with them. Ask what is excluded from a managed export, such as hosting-level configuration or third-party secrets. The step is done when the answers are in writing and each data category has a named method or a named gap.
Match Shopware line and runtime versions
Align the installed Shopware line, PHP version, database engine and version, and any search or cache services with what the target environment supports. Shopware 6.7.15.1 and 6.6.10.29 were both released on October 7, 2026, so confirm which maintained minor line your shop runs and which one the target supports. Check the PHP and database requirements for that line in the Shopware documentation. Where versions differ, decide whether to upgrade before the move or after it, and test each choice in staging. The step is done when a single target stack is documented and every extension is confirmed compatible with it.
Rehearse the move in a staging copy
Restore a recent export into a staging environment that matches the target stack, then run the full import and configuration steps without touching production. Record every manual action, every error and the total effort it took, because that record is the basis for the production runbook. Repeat the rehearsal until two consecutive runs produce the same result with no manual fixes. Confirm with the operator how long the production freeze window needs to be, since no timing figure is supplied for this page. The step is done when the runbook is tested end to end and the rehearsal log is approved.
Verify orders, customers, media and integrations
On staging, check the data that matters most to the business. Compare order counts, totals, statuses and invoice numbers against the source. Confirm customer accounts can log in, addresses and consent records are present, and product media and documents resolve correctly. Test each integration with a real test transaction, including payment callbacks, shipping labels, ERP sync and webhooks. Have finance sign off on a reconciliation sample. The step is done when every check has a recorded pass result and any mismatch has an owner and a fix.
Cut over DNS and payment configuration
During the agreed window, put the shop into maintenance mode, run the final incremental data sync, and switch DNS and payment provider settings to the target. Update webhook endpoints, return URLs and API credentials in each connected system. Keep the source read-only so no orders land in two places. Confirm payment authorizations and a test refund on the live environment before opening the shop. The step is done when the storefront, checkout and payment callbacks work on the new environment and the cutover log is signed off.
Keep the source for a rollback window
Retain the source environment, its database and its media store in read-only form for an agreed rollback period, and do not delete the old hosting account until that period ends. Set a checkpoint where the team decides whether to roll back, based on order and payment reconciliation. Note that the cost of moving back later depends on how much the shop has customized: extensions, custom plugins and third-party integrations each need their own port or retest. Ask the operator to quote the effort for a reverse move before you commit. The step is done when the rollback decision is recorded and the source is decommissioned under a written plan.
How DeployOpen scopes, delivers and supports self-hosted Shopware
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For Shopware, that means working out which hosting model fits your team and then delivering the self-hosted stack, cloud account or data center work that model requires, under a written scope.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which hosting model is in play, whether SaaS, PaaS on managed infrastructure or self-hosted, and who operates each layer.
- Scope records the Shopware edition, the plugins and integrations in use, and the customizations planned against the MIT-licensed core.
- Quotes follow from the written scope, so the cost drivers are visible to the buyer before any work begins.
How we build
- We deploy Shopware into your own cloud accounts, data centers or air-gapped networks, on the infrastructure your team already governs.
- Customizations and integrations are built against the target maintained minor line, so the upgrade path between lines is planned from day one.
- Security testing of the storefront, APIs and hosting layer is scoped alongside the build, not added after go-live.
- Configuration, hardening and backup routines are implemented and checked against your own recovery requirements.
How we hand over
- Handover includes documentation of the deployed architecture, configuration, customizations and operating procedures.
- Upgrade steps between Shopware minor lines are written down so your own team can repeat them without us.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any audit reports or certifications.
- Your team receives a clear map of which tasks remain with you and which move to a retainer.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should be confirmed in writing, including who applies Shopware minor-line upgrades and who monitors releases.
- Ask whether support covers the plugin and integration layer, not only the Shopware core, before signing.
- If your business moves between SaaS, PaaS and self-hosted later, the written scope should define how that migration is handled.
