---
title: Understanding Builds and Deployments | Shopware Community Hub
description: >-
Learn how builds, deployments, deployment status, and rollback work together
on Native PaaS so that rollouts can be followed and failures can be
interpreted…
canonical_url: 'https://hub.shopware.com/learn/unit/understanding-builds-and-deployments'
---
# Understanding Builds and Deployments
- Explain how a Git commit becomes a build and then a deployment.
- Distinguish build and deploy phases and locate failures correctly.
- Follow deployments using CLI tools, status views, and deployment details.
- Describe rollback as redeploying a known-good build.
# Understanding Builds and Deployments
Before you trigger deployments, it helps to separate three things clearly:
1. The Git commit,
2. The build created from that commit,
3. The deployment that applies a successful build to an application.
In this learning unit, you learn how code moves from repository state to a running Native PaaS application, how to follow that process in the CLI, and how to reason about failures and rollbacks without mixing up the phases.
## Build and Deploy Are Separate Steps
Build and deploy are related, but they are not the same action:
- A Git commit identifies the code state you want to release.
- A build turns that state into a deployable artifact.
- A deployment then applies a selected successful build to a target application.
That distinction lets you answer the most important operational question early: Did the problem happen while the application was being built, or after a build was deployed?
- Build-related issues usually appear while packaging the application and installing dependencies.
- Deploy-related issues usually appear when infrastructure, the Shopware application, or runtime configuration is applied.
With that distinction in mind, you can now look at how each phase appears in the CLI workflow.
### Build and Update in the CLI
When you want to trigger a build explicitly, use the build commands directly:
```bash
sw-paas application build start
sw-paas application build logs
```
This is useful when you want to create a new artifact from the current repository state and inspect the build phase on its own.
For the common case "ship what is on the branch now," teams often use `sw-paas application update`, which chains build and deploy in one flow.
Even in that combined flow, it still helps to think in two phases when you troubleshoot. A failure can still belong either to the build or to the deployment.
## End-to-End Deployment Flow
Once you separate build and deploy conceptually, the normal deployment flow becomes much easier to follow.
In practice, you are usually trying to answer one simple question: how does a code change move from the repository into one running application, and how do you follow that process with confidence?
In this model, deployments follow a simple sequence:
commit -> build -> deploy -> observe -> inspect
The flow below maps that sequence to the CLI.
1. Local or CI: Commit and push the Git state you want to make available for deployment.
2. Create a build from that repository state through your team's normal workflow.
3. When you want to deploy a specific successful build to an application, run:
```bash
sw-paas application deploy create
```
Use this command when you want to deploy one specific successful build to one application. The CLI lets you choose which build you want to deploy, which is why this command is also important when you need to redeploy an older successful build later.
Exact flags for application id and related parameters follow current CLI documentation.
4. Observe progress in real time:
```bash
sw-paas watch
```
Use this command while the deployment is running and you want live feedback instead of checking the result afterwards. This is the fastest way to see whether the process is still moving normally or whether it already failed in a specific phase.
You can also focus the live stream on specific applications:
```bash
sw-paas watch --application-ids app1,app2
```
Event-type filtering belongs to the deployment history commands, not to the basic `sw-paas watch` flow shown here.
5. When you need deployment details or status history for a specific deployment, use:
```bash
sw-paas application deploy get
```
Use this after the fact when you want to inspect one deployment more closely. This is especially useful when the live stream is already over and you want to review what happened in a more targeted way.
List recent deployments when you need history or status at a glance:
```bash
sw-paas application deploy list
```
This gives you the day-to-day operating pattern: choose a successful build for deployment, follow the rollout live, and then inspect one deployment in more detail if something looks wrong.
The key is always the same: ask in which phase the deployment currently is, or in which phase it failed.
### Deployment Status in the CLI
While a deployment runs, `sw-paas watch` streams updates that help you see whether the rollout is still moving.
For a quick overview, `sw-paas app list` shows two status columns:
| Status | What it tells you |
|---------------------------|----------------------------------------------------------------------------------------------|
| **Infrastructure Status** | Whether the platform infrastructure for the application is ready, still changing, or failed. |
| **Application Status** | Whether the Shopware application itself is ready, still deploying, or failed. |
That split is the useful first diagnostic step. It tells you whether you should start looking at the platform/infrastructure side or at the application deployment side.
When you need the detailed status history for one deployment, use `sw-paas application deploy get`. That view gives you the deployment-specific timeline instead of only the current overview status.
This status view answers one question: is the current problem closer to infrastructure readiness, or closer to the Shopware application rollout?
The next question is slightly different: Are you still dealing with a build problem or already with a deployment problem?
If you can place a failure in the right phase, you already know where to look first instead of troubleshooting everything at once.
### Roll Back by Redeploying an Older Build
At this point, it is worth understanding the role of rollbacks because this is one of the practical situations where the deployment model really matters.
Once that deployment model is clear, rollback also becomes easier to understand.
In many setups, there is no separate rollback button. A rollback means selecting a previous successful build in `sw-paas application deploy create` and deploying it again.
That brings the application back to the code state captured in that build. In other words, rollback is not a separate magic action. It is another deployment, but this time you deliberately choose an older successful build.
Do not force-push away commits that produced known-good builds. The [FAQ](https://developer.shopware.com/docs/products/paas/shopware/faq.html) notes that losing Git history can remove the ability to redeploy those artifacts.
## Timing (indicative)
Timing becomes easier to interpret once you understand build and deploy as separate phases.
The actual duration depends on what is being deployed, whether the application already exists, and whether extra work such as database migrations is part of the rollout.
The following ranges come from enablement observations, not from formal SLAs:
- New application (cold): about 3–5 minutes to provision database, object storage, caches, app nodes, and related resources.
- Existing application, no heavy migrations: on the order of 30–60 seconds for the deploy step.
- Database migrations: can add about a minute or more depending on schema changes.
- In typical cases, a deploy may also take on the order of two minutes depending on the environment and the work involved.
These numbers help you set expectations more realistically. A deployment is not automatically "stuck" just because it takes longer than the fastest happy-path case.
## Ephemeral applications
Ephemeral applications are useful when you want to validate a change in a short-lived environment without treating it like a permanent staging or production application.
They are especially useful in the build-and-deploy context when you want to validate a change after deployment without affecting long-lived environments.
That means you can check how a specific change behaves, use the environment for QA or debugging, and then let it expire instead of operating it long term.
Create short-lived instances with the ephemeral flag (see `sw-paas application create --help` for the exact syntax).
Ephemeral applications are cleaned up automatically by the platform. Do not plan with a fixed lifetime such as "24 hours", because the actual available time depends on when the cleanup runs. Treat them as temporary validation environments, not as production systems, reliable handover environments, or long-lived staging replacements.
## Check your understanding
Use these questions to check the two core ideas from this learning unit: what a deployment is tied to, and why build and deploy must still be separated mentally.
What is a Native PaaS deployment based on?
The latest manual change in the Shopware administration
A selected successful build created from a specific Git commit
The last state still left on the server disk
Why are build logs and deploy logs kept separate?
Because both phases always succeed or fail together
Because build and deploy are different steps with different responsibilities
Because deployment history does not include technical details
## Summary
In this learning unit, you learned:
- A deployment is always tied to a specific build created from a Git commit.
- Build and deploy are separate phases that must be reasoned about independently.
- CLI tools and deployment status views help you locate failures quickly.
- Rollback means redeploying a known-good build.
With this understanding, you can follow deployments more confidently, interpret failures more precisely, and make release and rollback decisions with a clearer mental model.