---
title: What is Shopware PaaS and When to Use It | Shopware Community Hub
description: >-
  Learn how Shopware PaaS Native differs from Upsun-based Shopware PaaS,
  self-hosted setups, and SaaS so that you can judge when it fits a project and…
canonical_url: 'https://hub.shopware.com/learn/unit/what-is-shopware-paas-and-when-to-use-it'
---

# What is Shopware PaaS and When to Use It

<LearningObjectives>

- Position Shopware PaaS Native within the hosting spectrum and compare it to Upsun-based PaaS.
- Distinguish responsibilities between your team and the platform.
- Decide whether Native PaaS fits a given project scenario.
- Identify platform boundaries and cases that need an early architecture check.

</LearningObjectives>

# What is Shopware PaaS and When to Use It

Before you work with access, repositories, or deployments, you need a clear mental model of what Native PaaS actually is.

In this learning unit, you place Native PaaS in the larger hosting picture, compare it with Upsun-based Shopware PaaS, and clarify who is responsible for what on the platform.

This gives you the foundation you need for the more practical units that follow.

## Why Another PaaS?

Shopware already offers Shopware PaaS on Upsun (see [Shopware PaaS Essentials](/learn/path/shopware-paas-essentials)). It is a flexible, multi-purpose platform that is already proven in many projects.

Shopware PaaS Native is Shopware’s own PaaS for Shopware 6 projects. It aims for lower operational effort, stronger platform defaults, and performance patterns tuned for Shopware. In other words, Native is not a generic “run anything” PaaS.

<Callout title="Strategic Direction" type="info">

Enablement positions Native PaaS as the long-term Shopware-hosted path. Upsun remains relevant for versatility and existing projects. Licensing, timeline, and migration are defined by your sales and account teams, so this learning unit stays focused on technical positioning.

</Callout>

## Reminder: On-Prem vs. PaaS vs. SaaS

Before comparing Native with Upsun in more detail, it helps to place both in the bigger hosting picture. Shopware projects usually sit somewhere between SaaS, PaaS, and self-hosted setups (same mental model as [Shopware hosting solutions](/learn/path/hosting-solutions-shopware6-cloud) in the DevOps path).

The diagram gives the quick orientation. The table below shows the main differences:

```mermaid
graph LR
    SaaS["Shopware SaaS<br/>Lowest ops burden"]
    PaaS["PaaS Native / Upsun<br/>You own code and Git ops"]
    SelfHosted["Self-hosted<br/>You own platform and servers"]

    SaaS --- PaaS --- SelfHosted

    style SaaS fill:#e3f2fd
    style PaaS fill:#fff8e1
    style SelfHosted fill:#e8f5e9
```

| Dimension | Self-Hosted | PaaS (Native or Upsun) | Shopware SaaS |
|-----------|-------------|-------------------------|----------------|
| Who runs servers & platform | You | Provider (Shopware + cloud partners) | Provider |
| Who controls Shopware code & extensions | You | You | Constrained by SaaS rules |
| Customization depth | Highest | High (within platform rules) | Lower |
| Ops effort | Highest | Medium (you focus on app + Git ops) | Lowest |

PaaS lets the team focus on the Shopware project while the platform handles scaling, patching, managed services, and standardized deploy paths.

## Resource Hierarchy

Once you place Native PaaS in the hosting spectrum, the next question is how the platform is structured.

Everything in Native PaaS nests in three levels:

- **Organization**: Your company or billing anchor.
- **Project**: One Git repository.
- **Application**: A running shop tied to a deployed **commit SHA**.

One organization can hold many projects. Each project can have several applications, for example production, staging, and short-lived ephemerals.

Access follows the same hierarchy. Human users can receive memberships for organizations, projects, or applications. Automation should use service accounts and tokens instead of a personal user session.

For a first orientation, keep these role names in mind:

| Role | Typical use |
|------|-------------|
| `read-only` | Auditors, stakeholders who only need visibility |
| `developer` | Day-to-day builds, deploys, and application work |
| `project-admin` | Team leads managing users and settings alongside dev work |
| `account-admin` | Account and user management |

You will use the CLI against an organization and project context after authentication ([Setting Up Access and CLI Tooling](/learn/unit/setting-up-access-and-cli-tooling)).

## Native vs. Upsun

Now that the basic structure is clear, you can compare the two PaaS models more directly.

| Aspect | Upsun-based Shopware PaaS | Shopware PaaS Native |
|---|---------------------------|----------------------|
| Best suited for | Broader project shapes; extra workloads may be possible | Shopware 6 projects with a more opinionated platform model |
| Flexibility | Higher flexibility | Constrained by design for performance and simplicity |
| HTTP / CDN layer | More generic platform setup | Fastly with Shopware-oriented VCL (Varnish Configuration Language) defaults for HTTP and caching behavior |
| Extra app servers | More natural to discuss in some setups | Not on the same stack; host standalone Java or Node services separately |

Choose Native when you want strong Shopware alignment and are willing to stay inside the supported patterns. Choose Upsun when you need more flexibility or already run there today.

## When to Choose Native PaaS

That comparison becomes practical when you look at the kinds of projects Native PaaS supports well.

Native PaaS is a good fit when you want to stay close to Shopware’s supported platform model:

- Standard Shopware 6 shops and extensions installed via Composer and Git.
- Teams that accept CLI-first operations and Vault-backed secrets.
- Teams that want managed MySQL, S3 object storage, OpenSearch, Fastly, and Grafana without building that stack themselves.

Native PaaS needs an early architecture check when your project depends on patterns outside that model:

- Composable Frontends (CFE) or heavily decoupled frontend setups that need their own runtime decisions.
- Requirement to co-host a custom Java/Node middleware on the same PaaS runtime (use separate hosting; integrate via HTTP/API).
- Need for deep web server or PHP-FPM tuning at the node level (not exposed—negotiate with Shopware if a strong business case exists).

Rule of thumb: Choose Native when you want a Shopware-first platform with clear conventions. Clarify the target architecture early when your project depends on flexibility outside those conventions.

## Responsibilities on Native PaaS: Who Does What

If Native PaaS is a good fit for your project, the next question is where your responsibilities end and Shopware’s begin.

Native PaaS reduces infrastructure work, but it does not remove application ownership. To use the platform well, you need a clear picture of what stays with your team and what Shopware operates for you.

Your team (partner / merchant)

- Custom plugins, themes, and integrations, plus Composer dependency hygiene and the security of your code.
- When to deploy, and how to manage environment-specific configuration and secrets (via Vault and YAML).
- Application-level monitoring and debugging (slow queries, N+1 patterns, extension bugs).

Shopware (platform)

- Provisioning, HA, patching, and infrastructure security controls (WAF, GuardDuty-class tooling, ISO 27001 posture—per enablement).
- Backups and recovery processes; uptime targets (formal SLA may be WIP).
- Deployment pipeline enablement: build/deploy separation, CLI and UI, access to logs and metrics.

Based on these responsibilities, it helps to think in two conceptual layers when talking to stakeholders.

- The **infrastructure** layer (Kubernetes, AWS services, networking, Fastly) is run by Shopware and mostly stays invisible.
- The **platform** layer (`sw-paas` CLI, build pipeline, Vault, Grafana) is the part you use day to day.

## What Native PaaS Provides

Once these roles are clear, it helps to see the concrete platform building blocks you will work with most often.

These are the platform building blocks you will work with most often:

- **Deployments**: Git-based deployments via `sw-paas` (no FTP or ad hoc file sync).
- **HTTP and caching**: Fastly CDN on applications, with Shopware-oriented defaults.
- **Observability**: Grafana-based access to operational signals such as logs, metrics, and traces.
- **Secrets and access**: Vault for secrets, SSH deploy keys, human user access, service accounts, and tokens.
- **Managed data services**: an isolated data plane per application, for example dedicated MySQL and S3 buckets. You will look at these services in more detail in the Runtime course.

<Callout title="Common Misconceptions" type="warning">

- **Not generic container hosting:** you do not manage Kubernetes manifests or SSH into nodes; interactive access is via platform-supported commands, not root shells.
- **Shopware-only workloads:** arbitrary Node/Java services on the same stack are out of scope—integrate external services over HTTP/API if needed.
- **Runtime extension installs:** the plugin manager in the Shopware administration is not the source of truth on environments rebuilt from Git; Composer and Vault-backed auth are ([Preparing Your Project Repository](/learn/unit/preparing-your-project-repository)).

</Callout>

## Check Your Understanding

Use these questions to check the two core ideas from this learning unit: How Native differs from Upsun and who is responsible for what on the platform.

<ArticleMultipleQuestionnaire>
  <ArticleQuestionnaire>
    <ArticleQuestionnaireQuestion>Compared with Upsun-based Shopware PaaS, what is the main focus of Shopware PaaS Native?</ArticleQuestionnaireQuestion>
    <ArticleQuestionnaireAnswer>Maximum flexibility to run arbitrary extra runtimes on the same stack</ArticleQuestionnaireAnswer>
    <ArticleQuestionnaireAnswer correct>Strong Shopware 6 defaults and conventions, with less “run anything” flexibility</ArticleQuestionnaireAnswer>
    <ArticleQuestionnaireAnswer>Identical workflows and feature parity so teams can switch without learning new tools</ArticleQuestionnaireAnswer>
  </ArticleQuestionnaire>
  <ArticleQuestionnaire>
    <ArticleQuestionnaireQuestion>According to the responsibility split in this unit, who primarily owns custom plugins, themes, and Composer dependency hygiene?</ArticleQuestionnaireQuestion>
    <ArticleQuestionnaireAnswer>Shopware</ArticleQuestionnaireAnswer>
    <ArticleQuestionnaireAnswer correct>Your team (partner or merchant team)</ArticleQuestionnaireAnswer>
  </ArticleQuestionnaire>
</ArticleMultipleQuestionnaire>

## Summary

In this learning unit, you learned:

- How Shopware PaaS Native differs from self-hosted setups, Upsun-based Shopware PaaS, and Shopware SaaS.
- How Native PaaS is structured across organizations, projects, and applications.
- When Native PaaS is a good fit for a project and when the target architecture needs a closer check.
- Which responsibilities stay with your team and which parts are operated by Shopware.
- Which platform building blocks Native PaaS provides, and which common misconceptions to avoid.

With this knowledge, you can better judge whether Native PaaS fits your project and talk about the platform with a clearer mental model.