---
title: Choosing the Right Shopware Setup | Shopware Community Hub
description: >-
  Learn which local Shopware setup to use before starting the developer learning
  paths.
canonical_url: >-
  https://hub.shopware.comhttps://hub.shopware.com/learn/unit/choosing-the-right-shopware-setup
---

# Choosing the Right Shopware Setup

<LearningObjectives>

- Choose the right Shopware setup for the developer learning paths.
- Learn the difference between normal Shopware project setups and the Shopware platform repository.
- Understand why commands, helper scripts, and folder paths can differ between project and platform contexts.

</LearningObjectives>

# Choosing the Right Shopware Setup

Before you install Shopware locally, make sure you start in the right project setup.

The developer learning paths assume that you work in a normal Shopware project. This is the setup you use when you build a shop, develop plugins, create apps, build themes, or change project-specific configuration.

## Start With a Normal Shopware Project

For our developer learning paths, use a Shopware project created from the production template.

You can create such a project in different ways:

- With [Shopware CLI](https://developer.shopware.com/docs/guides/installation/): `shopware-cli project create`
- With the Docker-based setup shown in the next installation units
- With Composer: `composer create-project shopware/production <project-name>`

The installation method can differ. The important point is that you work inside a normal Shopware project structure with files and folders such as:

- `bin/console`
- `custom/plugins`
- `custom/apps`
- project-level configuration files

Later learning units use these files, folders, and commands in their examples.

## How the Names Fit Together

Some Shopware project names look similar, but they describe different things.

`shopware/template` is the source behind the Shopware project template. You usually do not clone this repository directly for these learning paths.

When you create a project with Composer, the project can appear as `shopware/production` in `composer.json`. This is the Composer project created from the production template.

Shopware CLI and the Docker-based setup also help you create or prepare a normal Shopware project, so you can work in the expected project structure.

<Callout title="Project Setup vs. Platform Repository" type="info">

[`shopware/shopware`](https://github.com/shopware/shopware) is the Shopware platform repository. It is mainly used when you want to contribute to Shopware itself, for example to work on the core, the administration, the storefront, or platform-level changes.

For the developer learning paths, start with a normal Shopware project created from the production template. The learning paths are written for project development, not for contributing directly to the platform repository.

</Callout>

### Why Commands Can Differ

Project commands depend on the setup you are working in. A normal Shopware project and the `shopware/shopware` platform repository are different contexts.

Because of that, helper commands, watcher commands, build commands, or paths such as `custom/plugins` and `custom/apps` may not work in the same way across both contexts.

If a command is missing or behaves differently, you are not stuck, and your installation is not automatically wrong. It usually means that you need to check which setup context you are working in. For the developer learning paths, continue with a Shopware project created from the production template. The next two learning units guide you through this setup on macOS and on Windows with WSL2.

## Summary

For the developer learning paths, start with a normal Shopware project created from the production template. You can create this setup with Shopware CLI, the Docker-based setup, or Composer.

**Do not start with `shopware/shopware` for these learning paths.** Use it only when you want to work on the Shopware platform itself. It is a different setup context, so commands, helper scripts, and folders can differ there.