Review Apps for Magento: Worth It or a Waste of Time?

1. What Review Apps are and what they promise

Review Apps are dynamic environments in GitLab that spin up automatically for every merge request and get torn down again once the merge request is merged or closed. The concept originally comes from the world of web apps running on Kubernetes or on platform-as-a-service offerings like Heroku: a feature branch gets its own URL, and the team can test the changes directly in the browser before the code is integrated into the main branch.

The promise is appealing: no switching to staging, no manual deployments for QA, no collisions between several developers on the same test environment. Every merge request has its own isolated state. Design reviews, product manager sign offs and manual tests can happen directly on the preview URL, without a developer needing to be present to explain or deploy the current state.

For simple web applications without persistent data and complex infrastructure, this concept really is powerful. For Magento the reality looks different, and it is worth looking at that reality honestly before investing weeks into building a Review App infrastructure that ends up barely being used in practice.

2. Why Magento makes Review Apps complicated

Magento is one of the most complex PHP applications operated in production environments. A full Magento stack includes PHP, MySQL or MariaDB, Elasticsearch or OpenSearch, Redis for caching and sessions, RabbitMQ for the queue, Varnish for HTTP caching, and a web server. A complete Review App would need to spin up an instance of every one of these services for each merge request, either as Docker containers or as managed services.

Then there is the question of database state. Magento without product data is not testable. An empty shop shows no product pages, no checkout, no relevant storefront features. A Review App therefore needs either a copy of the production database, which is problematic both legally and operationally, or a generated test dataset that has to be maintained and kept up to date. The frontend build with Tailwind CSS and the dependency injection compilation take several minutes. Depending on the use case, a Review App can mean 10 to 20 minutes of waiting before it is usable.

3. When Review Apps make sense for Magento

There are scenarios where the effort behind Review Apps is justified. The first is a large team with many parallel feature branches and frequent design or product manager reviews. If five developers are working on storefront features at the same time and external reviews are needed regularly, the infrastructure pays off. A second scenario is pure frontend changes: if a merge request touches only Hyva templates, Tailwind CSS classes or Alpine.js components, a Review App that deploys just the build output, without the full Magento backend stack, is enough.

A third scenario is Magento projects running on Kubernetes, where the container infrastructure already exists and a new Magento instance can be spun up in minutes through Helm chart variables. In this case the overhead is significantly lower than on classic VMs. Here a Review App can genuinely make sense, provided the team already has experience with Kubernetes and Magento container deployments.

4. When Review Apps are a waste of time

For the majority of Magento projects, small to medium shops, classic VM infrastructure, teams of 2 to 5 developers, the effort clearly outweighs the benefit. Running Review Apps requires: orchestrating DB dumps or test data, automating the Magento installation process for every environment, cleanup routines for torn down environments, DNS configuration for dynamic subdomains, and monitoring for many parallel instances.

That is a dedicated infrastructure task that requires weeks of setup time and ongoing maintenance. If the goal was to get faster feedback on merge requests, there are more pragmatic routes, in particular a well configured staging environment combined with automated screenshot tests. The classic mistake is treating Review Apps as a simple feature that gets "quickly switched on", only to discover months later that the infrastructure needs more care than the actual shop code.

# .gitlab-ci.yml - Minimal Review App for frontend-only Magento changes
# Only suitable when the MR contains ONLY Hyva template / Tailwind changes

review:start:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: review:stop
    auto_stop_in: 2 days
  script:
    # Build frontend assets for this branch
    - npm ci --prefix app/design/frontend/Mironsoft/default/web/tailwind
    - npm run build --prefix app/design/frontend/Mironsoft/default/web/tailwind
    # Deploy static files only to review subdomain - no full Magento stack
    - rsync -az pub/static/ "${REVIEW_DEPLOY_USER}@${REVIEW_HOST}:${REVIEW_PATH}/${CI_COMMIT_REF_SLUG}/pub/static/"
    - ssh "${REVIEW_DEPLOY_USER}@${REVIEW_HOST}" "ln -sfn ${REVIEW_PATH}/${CI_COMMIT_REF_SLUG} ${REVIEW_PATH}/current-${CI_COMMIT_REF_SLUG}"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
      allow_failure: true

review:stop:
  stage: deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  script:
    - ssh "${REVIEW_DEPLOY_USER}@${REVIEW_HOST}" "rm -rf ${REVIEW_PATH}/${CI_COMMIT_REF_SLUG}"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual

5. Building a minimal Review App for Magento

If Review Apps are still going to be used, we recommend a pragmatic approach: not a full Magento instance per merge request, but a shared base Magento instance on staging that only receives the frontend build and templates of the respective branch. This means: a staging Magento instance runs permanently with a current product dataset. For every Review App deploy, only the Hyva build is transferred and the symlink to the active static content directory is switched over.

This variant saves the expensive database orchestration while still providing real product data and enabling realistic frontend reviews. The downside: two branches cannot be reviewed at the same time without causing conflicts. For teams with a low volume of parallel reviews that is acceptable. For teams with higher parallelism a queue based solution becomes necessary, and only then does the infrastructure effort get high enough that the question of return on investment is justified.

6. Pragmatic alternatives to full Review Apps

The first alternative is automated screenshot tests: after every merge request build, a headless browser test runs, screenshots the most important storefront pages, and attaches the screenshots to the MR as a GitLab artifact. The review team sees the changes without opening a dedicated URL. Tools like Playwright or Puppeteer are well suited for this and run in the same Docker container as the build.

The second alternative is a branch deploy to staging with a manual trigger: every developer can deploy their branch to staging via a manually triggered GitLab job, have the changes reviewed there, and then switch staging back to the current state afterwards. This is less automated than Review Apps, but considerably simpler to operate and requires no dynamic DNS infrastructure.

# Alternative to Review Apps: screenshot test as MR artifact
screenshot:test:
  stage: verify
  image: mcr.microsoft.com/playwright:v1.44.0-jammy
  script:
    # Run Playwright tests against staging - captures screenshots of key pages
    - npx playwright test --reporter=html
  artifacts:
    when: always
    paths:
      - playwright-report/
    expire_in: 7 days
    expose_as: "Visual Regression Report"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Manual branch deploy to shared staging - simpler than full Review Apps
deploy:staging:branch:
  stage: deploy
  environment:
    name: staging
    url: https://staging.example.com
  script:
    - ./scripts/deploy.sh
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
      allow_failure: true

7. Staging as a shared review environment

The most proven and easiest to operate solution for most Magento projects is a well maintained staging environment that serves as the shared review base. Staging has product data, all Magento services are running, and every branch can be deployed to it via a manual GitLab job. The team always reviews on the same URL: no dynamic subdomains, no DNS chaos, no spinning environments up and down.

The key is that staging is always ready and stays stable. That means: automatic deployments to staging run on the main branch, branch deployments to staging are manual and explicit. After a review, staging gets reset manually or automatically to the current main state. This simple convention solves the parallelism problem: there is no issue as long as only one branch needs to be reviewed at a time.

8. Review Apps vs. staging: comparing the approaches

The decision between full Review Apps and a staging based review process depends on team size, infrastructure and review frequency. For most Magento projects, staging delivers the better return on investment.

9. Summary

Review Apps for Magento are not a bad concept, but one that underestimates the infrastructure complexity of Magento. For small and medium Magento teams, a well configured staging environment with manual branch deploy and screenshot tests is the clearly more effective and more cost efficient solution. Review Apps only pay off once the team is large enough to need parallel reviews, and the infrastructure (Kubernetes or similar) is already in place.

The most important takeaway: Review Apps are not a feature you "just switch on". They are an infrastructure project with ongoing costs for setup, operation and maintenance. Whoever knows and accepts these costs can create real value with Review Apps. Whoever treats them as a quick fix will end up frustrated, and will likely never open half of the review URLs.

10. Common mistakes with Review Apps for Magento

The most common mistake is underestimating the database question. Teams start with Review Apps without a clear plan for test data, and then discover that a Review App without real products cannot be reviewed by product managers and designers. The fix, anonymized DB dumps or generated test data, turns into a costly side project and delays the rollout of Review Apps by weeks.

A second mistake is forgetting the cleanup routines. Review Apps that do not get torn down after the MR is merged or closed permanently tie up server resources and DNS entries. After a few weeks you end up with dozens of dead Review App directories on the server and no longer know which ones are still active. The on_stop directive in GitLab and automatic cleanup jobs with auto_stop_in need to be configured from the start.

11. FAQ: Review Apps for Magento