How to Create a PrestaShop Staging Site

Why You Need a Staging Site

Every PrestaShop store owner eventually faces the same dilemma: you need to update a module, change your theme, or test a new feature — but doing it on your live store risks breaking something your customers depend on. A staging site solves this by giving you an identical copy of your shop where you can test freely without consequences.

If you've ever updated a module and watched your homepage break, or installed a new theme only to find your checkout stopped working — a staging environment would have caught that before any customer saw it.

A staging site is not a luxury — it's the bare minimum for running a professional e-commerce store. The cost of one hour of downtime during peak traffic far exceeds the effort of maintaining a test environment.

What Exactly Is a Staging Site?

A staging site is a complete clone of your production store — same database, same files, same configuration — running on a separate URL that only you (and your team) can access. It looks and behaves exactly like your real shop, but customers never see it.

Think of it as a dress rehearsal. You test everything on staging first, confirm it works, then apply the same changes to your live store.

What a Staging Site IS

• An exact copy of your production store's files and database
• Running on a separate domain or subdomain (e.g., staging.yourshop.com)
• Password-protected or IP-restricted so only your team can access it
• A safe place to test updates, new modules, theme changes, and PHP upgrades

What a Staging Site IS NOT

• A development environment for building custom code from scratch (that's a dev environment)
• A backup solution (backups are separate — never rely on staging as your only backup)
• Something you set up once and forget — it needs to be refreshed regularly from production

Option 1: Docker-Based Staging (Recommended)

Docker is by far the cleanest way to run a PrestaShop staging environment. It gives you isolated, reproducible environments that you can spin up and tear down in minutes. This is what we use internally for all our module development and testing.

Prerequisites

• A Linux server or VPS with at least 2GB RAM (4GB recommended)
• Docker and Docker Compose installed
• SSH access to both your production server and your staging server
• Basic comfort with the command line

Step 1: Set Up the Docker Environment

Create a directory for your staging project and a docker-compose.yml file:

mkdir ~/staging-shop && cd ~/staging-shop

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: staging-shop
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=root
      - DB_PASSWD=your_secure_password
    volumes:
      - ./html:/var/www/html
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mysql:5.7
    container_name: staging-shop-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Important: Match the PrestaShop image version to your production version. If you're running PS 1.7.8, use prestashop/prestashop:1.7.8. If PS 8.1, use prestashop/prestashop:8.1.

Step 2: Export Your Production Database

SSH into your production server and dump the database:

# On your production server
mysqldump -u root -p prestashop > ~/prestashop_backup.sql

# Download to your local machine / staging server
scp user@production-server:~/prestashop_backup.sql ./

Step 3: Import Into Staging

# Start the containers
docker compose up -d

# Wait ~30 seconds for MySQL to initialize, then import
docker exec -i staging-shop-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Step 4: Copy Production Files

# Sync your production files to the staging html directory
rsync -avz --delete \
  user@production-server:/var/www/html/ \
  ./html/ \
  --exclude='var/cache/*' \
  --exclude='var/logs/*' \
  --exclude='app/config/parameters.php'

Step 5: Update Configuration

After importing, update the shop URL in the database to point to your staging domain:

docker exec -i staging-shop-db mysql -u root -pyour_secure_password prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

Then update html/app/config/parameters.php with the staging database credentials (matching your docker-compose.yml).

Finally, clear the cache:

docker exec staging-shop rm -rf /var/www/html/var/cache/*

Option 2: Subdomain on Shared Hosting

If you're on shared hosting (cPanel, Plesk, DirectAdmin), Docker isn't available. Instead, you'll create a subdomain with its own document root and database.

Step 1: Create the Subdomain

In your hosting panel:

1. Go to Subdomains or Domains
2. Create staging.yourshop.com
3. Point it to a new directory, e.g., /home/user/staging.yourshop.com

Step 2: Create a New Database

In your hosting panel:

1. Go to MySQL Databases
2. Create a new database (e.g., user_staging)
3. Create or assign a user with full privileges on that database

Step 3: Copy Files

Use SSH or the File Manager to copy your entire PrestaShop installation to the staging directory. If you have SSH:

cp -r /home/user/public_html/* /home/user/staging.yourshop.com/

Step 4: Export and Import Database

# Export production
mysqldump -u user -p production_db > ~/staging_import.sql

# Import to staging
mysql -u user -p staging_db < ~/staging_import.sql

Step 5: Update Configuration

Edit app/config/parameters.php (or config/settings.inc.php on PS 1.6) to point to the staging database. Update shop URLs in the database as shown in Option 1, Step 5.

Option 3: Local Development with XAMPP/MAMP

For quick local testing, XAMPP (Windows/Linux) or MAMP (macOS) work fine. The process is similar to shared hosting — create a database, copy files, import the dump, update config. This is fastest for solo developers who just need to test a module quickly.

The downside is that your local environment may differ from production (different PHP version, different MySQL version, missing extensions), so always do a final test on a server-based staging before deploying to production.

Essential Post-Setup Steps

Disable Outgoing Emails

This is critical. Your staging site has a copy of your production database, which means it has real customer email addresses. If you trigger an order confirmation or a password reset on staging, those emails will go to real customers.

Go to Advanced Parameters → Email and either:

• Set the email method to "Never send emails" (safest), or
• Redirect all outgoing emails to a test address using a tool like Mailtrap

Disable Payment Gateways

If your staging site is connected to live payment processors (Stripe, PayPal), disable them immediately. You don't want accidental charges on real cards. Either:

• Disable all payment modules on staging, or
• Switch them to sandbox/test mode

Block Search Engines

Prevent your staging site from being indexed by search engines — duplicate content is an SEO nightmare:

• Go to Shop Parameters → Traffic & SEO and disable the sitemap
• Add a robots.txt that blocks all crawlers: User-agent: * / Disallow: /
• Better yet, restrict access entirely (see below)

Restrict Access

Your staging site should not be publicly accessible. Options:

• IP whitelist via .htaccess: Only allow your office/home IP
• HTTP Basic Auth: Add a password prompt via .htaccess
• PrestaShop Maintenance Mode: Enable it and whitelist your IP in Back Office → Shop Parameters → General → Maintenance

We recommend IP whitelisting in .htaccess as the most reliable method — maintenance mode can be bypassed, and basic auth sometimes conflicts with Ajax-heavy modules.

Keeping Staging in Sync

A staging site is only useful if it reflects your current production environment. Refresh it regularly:

When to Refresh

• Before any major update (PrestaShop core upgrade, large module update)
• At least monthly if you're actively developing
• After significant catalog changes (new categories, changed product structure)

Quick Refresh Script (Docker)

#!/bin/bash
# refresh-staging.sh — Pull latest production data into staging

# 1. Dump production DB
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. Import to staging
docker exec -i staging-shop-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. Fix URLs
docker exec -i staging-shop-db mysql -u root -p'your_secure_password' prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

# 4. Sync files
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Clear cache
docker exec staging-shop rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Common Mistakes to Avoid

Using Production API Keys on Staging

If your production store connects to Stripe, PayPal, shipping APIs, or any external service — those API keys are now on your staging site too. Always switch to sandbox/test keys on staging to avoid:

• Charging real customers from test orders
• Sending real shipment requests to carriers
• Hitting API rate limits that affect your live store

Forgetting to Disable Cron Jobs

If your production store has cron jobs (cart reminders, stock sync, feed generation), those crons might also run on staging if the URLs are similar. Disable or comment out any staging-related cron entries.

Testing with the Live Store Open in Another Tab

If you're logged into both your staging and production back offices in the same browser, cookies can conflict. Use a separate browser or incognito window for staging.

When to Test on Staging vs. Production

Summary

Setting up a staging site takes about an hour the first time. Refreshing it takes 5 minutes once you have a script. The time investment pays for itself the first time you catch a breaking change before it hits your customers.

Docker is the best approach if you have a VPS or dedicated server. Subdomain cloning works on shared hosting. Either way — the important thing is that you have something between your code changes and your customers.

If you need help setting up a staging environment for testing our modules specifically, check out our Try Before You Buy program — every module includes a fully functional 30-day demo that you can install on your staging site to test before purchasing.