---
title: Go-Live Readiness and Operational Reality | Shopware Community Hub
description: >-
Learn how go-live readiness, custom domain setup, rollback planning, and
current Native PaaS limits fit together so that launch decisions and
maintenance…
canonical_url: 'https://hub.shopware.com/learn/unit/go-live-readiness-and-operational-reality'
---
# Go-Live Readiness and Operational Reality
- Check go-live readiness across domains, monitoring, release state, and operational basics.
- Configure custom domains by choosing the correct DNS pattern and verification flow.
- Distinguish redeploying a previous build from restoring data through snapshots or backup procedures.
- Communicate honestly about rollback as a manual or supported process while automation matures, SLA artifacts (WIP), billing visibility (WIP), and Composable Frontends (not supported yet).
# Go-Live Readiness and Operational Reality
Go-live on Native PaaS is not only about deploying code. You also need the right domain setup, realistic rollback expectations, and a maintenance plan for what happens after launch.
Launch risk often comes from operational assumptions, not from the application code alone. DNS can be wrong, rollback may not undo data changes, and platform limitations can affect decisions long before a project goes live.
In this learning unit, you learn how to prepare a safer go-live by checking the operational basics first, understanding what rollback can and cannot do, and reading current platform limitations realistically.
## Check Go-Live Readiness First
Before launch, confirm that the operational baseline is in place. This is the point where many teams discover that a deployment can be technically successful while the go-live is still operationally unready.
| Area | What to confirm before launch |
|-------------|---------------------------------------------------------------------------------------------------|
| Secrets | Vault is complete for production and temporary preview values are rotated. |
| License | The Shopware license key is available at runtime. |
| Composer | The lockfile matches the release and no unintended dev dependencies leak into production. |
| Performance | Staging was tested under realistic load and obvious bottlenecks such as N+1 issues were resolved. |
| DNS | TTL was lowered in time and the required record pattern was verified. |
| Monitoring | Grafana dashboards and basic on-call views are understood before launch. |
That way, go-live stays more than a deployment event. It becomes an operational readiness check.
## Configure Custom Domains Correctly
Custom domains are a typical launch blocker because the application can be ready while DNS or CDN configuration is still wrong.
On Native PaaS, custom domains are attached to an application with the `sw-paas domain create` command. Before that command can succeed, the public DNS records for the domain must already point to the expected CDN target.
The first thing to decide is which hostname type you are configuring at your DNS provider:
- **Non-apex** domains usually use a **CNAME** to `cdn.shopware.shop`.
- **Apex** domains use **A** and **AAAA** records that point to the current **Fastly CDN** targets from the official [CDN / custom domain](https://developer.shopware.com/docs/products/paas/shopware/cdn/) documentation.
This is the important mental model: You do not invent the A/AAAA values yourself, and they do not come from your DNS provider. They are the Fastly IPv4 and IPv6 targets documented by Shopware for Native PaaS. For apex domains, copy all documented A and AAAA records from the current documentation and verify them before cutover.
For apex domains, ownership verification also requires a **TXT** record at `_shopware-challenge.` with the expected `shopware-challenge=` value. You can retrieve the organization ID with `sw-paas org list`.
After that, the flow usually is:
1. Create or update the required DNS records.
2. Wait for DNS propagation.
3. Create the domain in the platform with `sw-paas domain create`.
4. Run a new deployment so the edge configuration picks up the hostname.
5. Align the related sales channel domains in the Shopware administration.
Before cutover, verify the expected DNS records with a tool such as `dig`:
- **CNAME** for subdomains
- **A/AAAA** for apex domains
- **TXT** for the ownership challenge
That way, domain and verification mistakes are caught before launch instead of during cutover.
## Understand What Rollback Can and Cannot Do
The next important operational question is rollback. This is also where teams often overestimate what a previous build can actually recover.
### Redeploying a Build Is Not the Same as Restoring Data
Redeploying a previous build restores the **application code** from an earlier commit image.
It does **not** automatically undo later **database** or **media** changes.
So a bad migration or destructive data job is not solved simply by putting older code back online.
For risky changes, create a snapshot first with `sw-paas snapshot create` and make sure the restore path is understood with Shopware support before you actually need it.
### Cloning Helps with Safe Preparation
When you need to duplicate an application's code, database, and filesystem inside the same organization, use `sw-paas application clone` as described in the official [clone application](https://developer.shopware.com/docs/products/paas/shopware/guides/clone-application.html) guide.
This is useful for staging refreshes or disaster-recovery rehearsals because it lets you prepare or validate changes in a safer copy of the environment.
It still needs follow-up work such as rotating Admin credentials and updating sales channel hostnames on the clone.
## Treat Rollback as Operational Reality, Not as a Button
Deployments are tied to a **Git commit SHA**, not to a branch label alone at runtime.
Native PaaS also does not provide a built-in promotion chain such as automatic dev-to-staging-to-production gates.
That means your release process still decides which SHA reaches which application and when.
For rollback planning, keep these current expectations in mind:
- A forward fix can mean redeploying a known-good commit SHA.
- Database restore or PITR scenarios still require coordination with Shopware if no written self-service restore procedure exists for your setup.
Managed MySQL backups still exist in the background, but customer-initiated restore paths may not be fully self-service.
So restore should be treated as an operational process to confirm, not as a hidden UI feature you can assume is always available.
## Read Platform Limits Realistically
Some go-live and maintenance decisions depend on platform boundaries rather than on the application alone.
That is why a few current limits should be treated as planning inputs rather than as small footnotes:
- **SLAs and uptime** belong in contracts, not in technical assumptions.
- **Composable Frontends (CFE)** are not currently supported on Native PaaS.
- **VPN / private connectivity** should be treated as case-by-case instead of assumed platform standard behavior.
This does not make the platform weak. It means architectural and commercial expectations should match the current platform reality.
## Check Your Understanding
Use these questions to check the two core ideas from this learning unit: custom domains need the correct DNS pattern before launch, and rollback on Native PaaS must be planned with realistic expectations.
Your team wants to attach `shop.example.com` as a custom domain for go-live. Which DNS setup should you usually expect before cutover?
Only an apex A record, because subdomains do not need ownership verification
A CNAME from `shop.example.com` to `cdn.shopware.shop` so traffic is routed through the CDN endpoint
MX records pointing to the application, because custom domains are verified through email routing
A bad deployment included a destructive data job. Redeploying yesterday's build brings the old code back, but the affected database rows are still changed. What should the team understand?
Redeploying an older build always restores application code, database state, and media in one step
Redeploying a build can restore code, but data restore needs its own snapshot or support-confirmed restore path
Rollback is impossible on Native PaaS, so the only valid fix is creating a new project
## Summary
In this learning unit, you learned:
- Which operational checks belong to go-live readiness before launch.
- How custom domain setup depends on the correct DNS pattern and verification flow.
- Why redeploying a previous build is different from restoring a database or media state.
- How rollback, backups, and platform limits should be treated as operational realities rather than assumed self-service features.
With this understanding, you can prepare go-live more carefully, avoid false rollback assumptions, and treat maintenance decisions on Native PaaS with more realistic expectations.