If your shop takes real orders, e-commerce VPS hosting is usually the right home for it, because of one page nobody can cache: the checkout. Product pages can come out of a cache in milliseconds, but once a visitor adds something to the cart, every page is built fresh by PHP and the database, and on shared hosting that work queues behind other people's sites. Every extra moment there can cost an order. In a study Deloitte ran for Google, a mobile site 0.1 seconds faster went with 8.4% more retail conversions.
The numbers first:
- Google's "good" line is LCP within 2.5 s, INP within 200 ms and CLS within 0.1. Only 39% of WooCommerce sites reach the LCP mark on mobile.
- Most of the fix is on the server: Nginx, PHP-FPM, MariaDB, Redis and HPOS, with cart and checkout kept out of the page cache.
- Card numbers belong on the payment provider's page. Back up and use a staging copy before every update.
- VPS Mini is a comfortable start for most new stores. Move to a VDS before a big sale, not during it.
What a tenth of a second is worth
Deloitte's Milliseconds Make Millions report, commissioned by Google and published in 2020, followed 37 brands in Europe and the US through four weeks of mobile traffic, about 30 million sessions. When a site got 0.1 seconds faster, retail conversions rose 8.4% and average order value 9.2%. Read the fine print. It is a regression over natural speed differences, not a controlled test, and the 0.1 seconds combines four lab metrics. One of them is maximum server latency, the slice your hosting decides.
Controlled tests agree: in an A/B test described on Google's web.dev, Vodafone Italy sold 8% more with a 31% better LCP.
Core Web Vitals, and where WooCommerce falls short
Core Web Vitals are Google's measurements of real visits: Largest Contentful Paint (LCP), the time until the biggest element, usually the product photo, appears; Interaction to Next Paint (INP), how fast the page reacts to a tap, which replaced First Input Delay on 12 March 2024; and Cumulative Layout Shift (CLS), how much the layout jumps. According to web.dev, good means an LCP of 2.5 seconds or less, an INP of 200 ms or less and a CLS of 0.1 or less at the 75th percentile of visits. Time to First Byte (TTFB), the wait for the server's first byte, comes before all three; web.dev suggests 0.8 seconds or less.
The HTTP Archive Web Almanac 2025 found WooCommerce on 35.4% of the online shops in its desktop crawl and 44.4% in its mobile crawl, more than any other platform. Yet only 39% of WooCommerce sites have a good mobile LCP, against 88% with a good INP. Most WooCommerce shops answer a tap quickly but take too long to show the page, and the loading part is what a server and a cache can fix.
E-commerce VPS hosting or shared hosting?
For a shop, the weak spot of shared hosting is concurrency. Ten customers checking out in the same minute means ten PHP processes and ten rounds of database queries that no page cache can answer, while the host sets PHP versions and limits for everyone at once. A VPS (virtual private server) is a virtual machine in a data centre with its own memory, disk and operating system; our VDS plans are the larger tier, with more memory, bigger NVMe disks and a 10 Gb/s port. On a VPS the memory and NVMe disk belong to the store and you have root, so you size PHP-FPM to the machine and add Redis and a real cron job.
Shopify suits owners who never want to touch a server, though deeper checkout changes there need Shopify Plus. And if your WooCommerce store is slow today, find out why before rebuilding elsewhere. The culprit is usually the hosting or one heavy plugin, and if it is the hosting, you can move the WordPress site to a VPS as it is, with a migration plugin.
WooCommerce, PrestaShop or Medusa?
| Platform | What it is | What it needs | Choose it if |
|---|---|---|---|
| WooCommerce (11.1.2, September 2026) | A WordPress plugin; PHP and MariaDB. | PHP memory limit of 256 MB or more, PHP 8.3+ recommended, MariaDB 10.6+. | You want the most extensions and people who know it. |
| PrestaShop (9.2.0, September 2026) | A standalone PHP shop built on Symfony. | PHP 8.1 to 8.5, memory_limit of at least 512M, MariaDB 10.2+ or MySQL 5.7+. | You prefer a dedicated shop back office to a plugin. |
| Medusa (v2.21.2, September 2026) | A headless Node.js framework without a storefront, MIT licensed apart from its Enterprise features. | At least 2 GB of RAM, Node.js 24 LTS (Medusa accepts 20.19+ or 22.12+), PostgreSQL, Redis, server and worker processes. | A developer builds your storefront and you need custom pricing or multi-warehouse stock. |
Pick WooCommerce unless you have a clear reason not to: it has the biggest pool of extensions and of freelancers who can fix it. Medusa is a framework rather than a shop, and as one commenter on its 2021 launch thread put it, the older platforms are complicated for a reason: taxes in many countries and separate B2B and B2C prices are hard however the backend is built. It suits a team with a developer on hand; a shop owner working alone will spend more time building than selling. Read the licence too: since 11 August 2026 Medusa's repository marks role-based admin permissions (RBAC) and single sign-on as Enterprise Edition code that needs a commercial agreement with the company, while the rest stays MIT.
The fast stack, in plain terms
- Nginx, the web server, sends images and CSS from disk and hands PHP requests on. Caddy does the same and fetches HTTPS certificates itself; our reverse proxy and SSL guide compares them.
- PHP-FPM runs a pool of PHP workers, each handling one request at a time;
pm.max_childrencaps how many. - MariaDB is the database. Its buffer pool keeps the busiest tables in RAM.
- Redis, as a persistent object cache, keeps database results in memory between requests.
- A page cache stores finished pages for visitors with an empty cart.
Caching rules are where shops break. WooCommerce's caching guide says Cart, Checkout and My Account must never be page-cached, and neither may visitors carrying the cookies woocommerce_cart_hash, woocommerce_items_in_cart or wp_woocommerce_session_. Get it wrong and shoppers see an empty cart, or someone else's. It is also why Redis matters more to a shop than to a blog: the page cache serves the window shoppers, the object cache serves the buyers.
High-Performance Order Storage (HPOS) keeps orders in WooCommerce's own tables instead of WordPress's posts and postmeta. It has been the default for new stores since WooCommerce 8.2 in October 2023, and WooCommerce claims up to 5 times faster order creation and 1.5 times faster checkout. One merchant with about 500,000 orders reported slower searches after switching (GitHub issue #41317), so migrate an older store on a staging copy first.
WooCommerce 11.0, released on 4 August 2026, added another default for new stores: product object caching. When a page asks for the same product several times, WooCommerce now builds it once and keeps it in memory until the request ends, and its developers measured variable products loading about 9 to 12% faster on product pages. That memory lasts for one request only, so it adds to Redis rather than replacing it. Stores created before 11.0 keep their old setting; switch on Cache Product Objects under WooCommerce > Settings > Advanced > Features after a test on staging, because an extension that changes product data with its own SQL queries, past WordPress's hooks, can leave stale values behind.
Hosting the shop at RS Computers
RS Computers runs KVM virtual servers in Amsterdam (Netherlands), Prishtina (Kosovo) and Dublin (Ireland). A shop spends its day reading and writing its database, and every plan keeps that database on NVMe storage. Each server has its own IPv4 and IPv6 address, and traffic is unmetered, on a 1 Gb/s port for VPS plans and 10 Gb/s for VDS, so a sale that takes off does not come back as a traffic bill. The free weekly backup covers the whole server and restores from the client area, the same place you upgrade when orders grow. Debian 13, used in the guide below, is one of the Linux images you can pick when you order.
Amsterdam and Dublin suit buyers in the EU, Prishtina those in Kosovo and the region, where local peering keeps the route to shoppers short. Order in one of the locations the plans page marks as available.
Sizing a shop server: memory, PHP workers and plans
For a new WooCommerce store with a modest catalogue, 2 GB of RAM works when Redis and a page cache carry the load, and 4 GB is the comfortable start, with room for more PHP workers and a bigger database cache. That is our guidance; WooCommerce itself only asks for a 256 MB PHP memory limit. We built the finished stack from the guide below and loaded WooCommerce with 30 test products. The VDS-sized test server we ran it on had 8 vCPU and 16 GB of RAM, and after serving its pages the whole stack used under 300 MB of that, with each PHP worker close to 100 MB. With an item in the cart, the uncached checkout page started arriving in about 0.13 seconds, measured on the server itself. Our vCPUs are shared, so size for your busiest hour.
| Plan | Shop size |
|---|---|
| VPS Nano (1 vCPU, 1 GB, 20 GB NVMe, 1 Gb/s) | Not a live shop. An uptime monitor watching your store from a second location, or a price monitor that checks competitors' product pages. |
| VPS Micro (2 vCPU, 2 GB, 40 GB NVMe, 1 Gb/s) | A new WooCommerce shop with a few hundred products, Redis and a page cache. Tight for PrestaShop. |
| VPS Mini (4 vCPU, 4 GB, 80 GB NVMe, 1 Gb/s) | Most WooCommerce or PrestaShop stores, or a Medusa backend whose storefront runs elsewhere. |
| VDS Small (4 vCPU, 8 GB, 240 GB NVMe, 10 Gb/s) | Busy stores before a big sale, or Medusa with its Next.js storefront on one machine. |
| VDS Medium (8 vCPU, 16 GB, 480 GB NVMe, 10 Gb/s) | Large catalogues and order histories in the hundreds of thousands, where MariaDB wants gigabytes of buffer pool. |
| VDS Large (16 vCPU, 32 GB, 960 GB NVMe, 10 Gb/s) | Agencies running many stores, or a high-traffic shop with its own search engine. |
How to set up WooCommerce on a Debian 13 VPS
This is the native install: Nginx, PHP 8.4, MariaDB 11.8 and Redis from Debian's packages, then WordPress and WooCommerce through WP-CLI, WordPress's official command-line tool. On Ubuntu 24.04, PHP is 8.3, so type 8.3 wherever a path or service name says 8.4. Replace words in capitals with your own values. New to SSH? Our Linux lab guide starts there.
1. Point the domain and open the firewall
Point A and AAAA records for YOUR_DOMAIN at the server, then run this block: it updates the system and opens only SSH, HTTP and HTTPS.
# as root
apt update && apt full-upgrade -y
apt install -y sudo curl ca-certificates ufw cron
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose
Answer y to the SSH warning. The status shows Status: active and ALLOW lines for 22, 80 and 443, plus (v6) copies. Moved SSH to another port? Allow that one before ufw enable, or you lock yourself out.
2. Install the stack
Install Nginx, MariaDB, Redis and PHP with the extensions WooCommerce uses, then check that each one answers.
# as root
apt install -y nginx mariadb-server redis-server php-fpm php-cli php-mysql php-curl php-gd php-intl php-mbstring php-xml php-zip php-bcmath php-imagick php-igbinary php-redis
systemctl is-active php8.4-fpm mariadb redis-server nginx
ls /run/php/
redis-cli ping
Expect active four times, a socket named php8.4-fpm.sock (Nginx needs that exact name) and PONG.
3. Create the database
This runs MariaDB's hardening script.
# as root
mariadb-secure-installation
On Debian 13 it opens with a note that MariaDB there is already secure by default, so expect it to change little. Press Enter at the password prompt, answer n to the two questions about root's authentication and password, and Y to the rest. It ends with Thanks for using MariaDB!
This block prints a random password, then creates a database and a user limited to it; use the printed password in place of DB_PASSWORD.
# as root
openssl rand -base64 24
mariadb -e "CREATE DATABASE shop CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'shop'@'localhost' IDENTIFIED BY 'DB_PASSWORD'; GRANT ALL PRIVILEGES ON shop.* TO 'shop'@'localhost'; FLUSH PRIVILEGES;"
mariadb -u shop -p -e 'SHOW DATABASES;'
Enter that password when asked; the table that follows includes shop.
4. Install WP-CLI and WordPress
This installs WP-CLI as the wp command, then WordPress, prompting for the database password and a new admin password, and gives pages readable addresses.
# as root (the lines starting with sudo -u run as the www-data user)
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp
wp --info
mkdir -p /var/www/shop
chown www-data:www-data /var/www/shop
cd /var/www/shop
sudo -u www-data wp core download
sudo -u www-data wp config create --dbname=shop --dbuser=shop --prompt=dbpass
sudo -u www-data wp core install --url=https://YOUR_DOMAIN --title="YOUR_SHOP_NAME" --admin_user=ADMIN_USER --admin_email=YOUR_EMAIL --prompt=admin_password
sudo -u www-data wp config set DISALLOW_FILE_EDIT true --raw
sudo -u www-data wp rewrite structure '/%postname%/'
wp --info ends with a line like WP-CLI version: 2.12.0, and every later command ends with a Success: line. The password prompts show what you type, and afterwards WP-CLI prints the whole command with the password filled in; that is normal, and the password still stays out of your shell history. A warning that WP-CLI failed to create /var/ is harmless; it only means downloads are not cached. The last line matters for a shop: an install from the command line leaves WordPress on plain addresses such as /?page_id=8, and this switches them to /checkout/ and /product/your-product/. wp runs as www-data, the PHP-FPM user, because as root it refuses ("YIKES! It looks like you're running this as root"), and --allow-root leaves root-owned files that break dashboard updates.
5. Raise PHP's limits
The shop's PHP limits go in a file of their own, then PHP-FPM restarts to read it.
# as root
cat > /etc/php/8.4/fpm/conf.d/99-shop.ini <<'EOF'
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 60
EOF
systemctl restart php8.4-fpm
PHP's defaults, 128M of memory and 2M uploads, are too small for product imports. Once the site is up, Tools > Site Health > Info > Server shows the new values.
6. Configure Nginx
Create the site file with nano /etc/, paste this, save with Ctrl+O and exit with Ctrl+X.
server {
listen 80;
listen [::]:80;
server_name YOUR_DOMAIN;
root /var/www/shop;
index index.php;
client_max_body_size 64m;
location / {
try_files $uri $uri/ /index.php?$args;
}
# deny rules must stay above the PHP block
location ~ /\.(?!well-known) { deny all; }
location ~* /(?:uploads|files)/.*\.php$ { deny all; }
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}
# WooCommerce's own rule for protected downloads
location ~* /wp-content/uploads/woocommerce_uploads/ {
if ( $upstream_http_x_accel_redirect = "" ) { return 403; }
internal;
}
}
This block enables the site, removes Debian's default one and tests the configuration.
# as root
ln -s /etc/nginx/sites-available/shop /etc/nginx/sites-enabled/shop
rm /etc/nginx/sites-enabled/default
nginx -t
systemctl reload nginx
nginx -t must say syntax is ok and test is successful. If the browser later shows 502 Bad Gateway, the socket in fastcgi_pass does not match what step 2 printed; fix it and reload.
7. Turn on HTTPS
Certbot fetches a free Let's Encrypt certificate and edits the site file for HTTPS, adding a redirect from plain HTTP.
# as root
apt install -y certbot python3-certbot-nginx
certbot --nginx -d YOUR_DOMAIN
certbot renew --dry-run
curl -I https://YOUR_DOMAIN
Certbot asks for an email address (Enter skips it), your acceptance of the Let's Encrypt terms and whether to share the address with the EFF, where either answer is fine. The dry run should succeed, and curl should show status 200 or a 301 or 302 redirect. A failed challenge means the DNS record from step 1 is missing or wrong.
8. Add WooCommerce, Redis and two-factor login
Now the shop itself. The block installs WooCommerce, Redis Object Cache and Two Factor, switches the object cache on and caps Redis at 256 MB, dropping the least recently used keys when it fills (use 128mb on VPS Micro).
# as root (the lines starting with sudo -u run as the www-data user)
cd /var/www/shop
sudo -u www-data wp config set WP_REDIS_PREFIX shop_
sudo -u www-data wp plugin install woocommerce redis-cache two-factor --activate
sudo -u www-data wp redis enable
printf 'maxmemory 256mb\nmaxmemory-policy allkeys-lru\n' >> /etc/redis/redis.conf
systemctl restart redis-server
sudo -u www-data wp redis status
Look for Success: Installed 3 of 3 plugins. and Status: Connected; redis-cli config get maxmemory-policy should answer allkeys-lru. If it says Not connected, check that redis-cli ping answers and that the WP_REDIS_PREFIX line sits above "That's all, stop editing!" in wp-config.php. WooCommerce switches a new store to HPOS and product object caching the first time an admin opens the dashboard; both then show under WooCommerce > Settings > Advanced > Features. The same visit puts the store in Coming soon mode, so visitors see a placeholder on the shop pages until you pick Live under WooCommerce > Settings > Site visibility. Each admin turns on two-factor login under Users > Profile.
9. Replace WP-Cron and lock the config
WP-Cron only runs when someone visits, which stalls WooCommerce's background queue on quiet nights. This block hands scheduled tasks to the system cron every five minutes (our choice, not an official figure) and makes wp-config.php read-only.
# as root (the line starting with sudo -u runs as the www-data user)
cd /var/www/shop
sudo -u www-data wp config set DISABLE_WP_CRON true --raw
echo '*/5 * * * * /usr/local/bin/wp --path=/var/www/shop cron event run --due-now --quiet' | crontab -u www-data -
crontab -u www-data -l
chmod 440 /var/www/shop/wp-config.php
crontab -u www-data -l prints your entry, and within the hour WooCommerce > Status > Scheduled Actions should show nothing past due. Before any later wp config set, run chmod 640 on the file first.
PrestaShop or Medusa instead
PrestaShop 9 runs on the same base. PrestaShop 9.2, released on 30 September 2026, supports PHP 8.1 to 8.5, so Debian's 8.4 is fine, and adds a native one-page checkout that you can swap for the classic four-page one in the back office. Set memory_limit to 512M, install with php install/ as www-data and delete the install folder straight away: in April 2026 security firm Sansec found more than 200 live PrestaShop shops with the installer still reachable. Medusa runs on Node.js with PostgreSQL and Redis. Use Node 24 LTS, supported until April 2028: Debian 13's own Node 20 reached end of life on 30 April 2026, and Medusa asks for Node 24 or lower if you install its Next.js starter storefront. Expect two processes: a server for the API and admin, a worker for background jobs. Run it as a normal user behind Nginx or Caddy; our database guide covers PostgreSQL.
Card payments: keep the card number off your server
PCI DSS is the card industry's security standard, and how much of it applies depends on where the card number travels. When customers type it into a page or card fields hosted by the payment provider, as with Stripe Checkout or Stripe Elements, it never touches your server, and you can usually validate with SAQ A, the shortest self-assessment questionnaire. If card data passes through your server, you are in SAQ D, which Stripe says can mean more than 300 security controls.
The PCI Security Standards Council announced on 30 January 2025 that the payment-page script requirements 6.4.3 and 11.6.1 drop out of SAQ A from 31 March 2025. In exchange, a merchant whose checkout embeds the provider's card form, for example in an iframe, confirms that the site is not susceptible to script attacks that could affect its e-commerce systems; the council's FAQ 1588 exempts shops that redirect the customer to the provider's own page from that check.
In practice the provider secures the card field, and every other script on your checkout page is your responsibility. In May 2026 Sansec reported a flaw in FunnelKit's Funnel Builder plugin that put more than 40,000 WooCommerce checkouts at risk, used to plant fake Google Tag Manager code that loaded card skimmers.
Against card-testing bots, turn on "Rate limit Checkout" under WooCommerce > Settings > Advanced > Features. It allows 3 checkout attempts per 60 seconds on the Checkout block that new stores use; the older shortcode checkout is not covered.
How do WooCommerce stores get hacked?
Plugins, not WordPress itself, are the usual way in. Patchstack's 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than the year before, with 91% of them in plugins. For heavily targeted flaws, the weighted median time to the first exploit was five hours. A monthly update habit is not enough.
- Two-factor login for every administrator and shop manager, and no user called admin, the first name bots guess.
- Fewer plugins. Delete the ones you deactivated "for now".
- Fewer outside scripts, because a trusted vendor can be breached too. On 14 September 2026 the email marketing platform Brevo served malware for about four hours to more than 100,000 customer sites, Sansec reported. On WordPress sites whose admins opened their own site in that window, it installed a backdoor plugin.
- SSH keys instead of passwords. Our Debian 13 image lets root sign in over SSH with a password, and step 1 leaves port 22 open. A fresh test server of ours logged 261 failed SSH logins from 7 addresses in its first 78 minutes online. Week 2 of the Linux lab guide moves you to keys in an order that avoids a lockout.
- Rate-limit
wp-login.phpwith Nginx'slimit_reqand turn off unused XML-RPC, but never lock the whole/wp-admin/folder: the storefront callsadmin-ajax.phpthere. - MariaDB and Redis stay on localhost, with ports 3306 and 6379 closed. Redis had a CVSS 10 flaw in October 2025 (CVE-2025-49844); Debian 13's package carries the fix, which only helps if you run
apt upgrade.
How do you update a live shop without losing orders?
Free weekly backups of the whole server are the safety net for the bad day, but think about what a full restore does to a shop. Restoring a backup from five days ago also restores the orders and stock levels of five days ago. Everything sold since vanishes from the database. The payments do not. So make your own backup right before every update, keep daily database dumps, and test updates on staging first. This block writes a dated database dump and file archive.
# as root
install -d -m 700 /var/backups/shop
mariadb-dump --single-transaction --quick shop | gzip > /var/backups/shop/db-$(date +%F-%H%M).sql.gz
tar -czf /var/backups/shop/files-$(date +%F-%H%M).tar.gz -C /var/www shop
ls -lh /var/backups/shop
You should see two files with today's date and a size above zero. Never keep backups in /tmp on Debian 13, which lives in RAM and empties at reboot, and copy them to another machine; our off-site backup guide automates that with restic.
For staging, restore these backups to a subdomain with its own database and WP_REDIS_PREFIX. Put the payment gateways in test mode and a password in front, like the password-protected staging server in our CI article. Staging will not catch everything: in a GitHub thread opened on WooCommerce 9.2.1 in August 2024, which grew to about 180 comments, stores describe in-stock products that suddenly showed as out of stock, with no single release to blame. So on the live shop, update WooCommerce first, run its database update when the dashboard asks, then the extensions, and place a test order after each round.
Point an uptime checker on a second server at the checkout page, not the cached home page. Uptime Kuma on a small second VPS is enough for that. A dashboard warning about past-due scheduled actions means the cron job from step 9 has stopped.
Before a sale: when to move from VPS to VDS
Sales traffic arrives in a wave: Shopify's report on Black Friday Cyber Monday 2025 put its peak at 12:01 p.m. Eastern time on Black Friday. Upgrade from the client area days before your sale, not that morning: the server keeps its data, but the upgrade needs a short reboot, so pick a quiet hour. VPS Mini to VDS Small doubles the memory and brings a 10 Gb/s port. These commands show the warning signs.
# as root
vmstat 5 6
redis-cli info stats | grep evicted_keys
grep max_children /var/log/php8.4-fpm.log
ps -C php-fpm8.4 -o pid,rss,cmd
In vmstat, the column headed st is time spent waiting for the physical processor; if it climbs in busy hours, move up. A growing evicted_keys count means Redis is full. A log line about reaching pm.max_children means customers queued for a PHP worker, and Debian's stock pool allows only five. Divide the memory you can spare by a worker's RSS from the ps list: workers near 100 MB with 2 GB to spare gives about 20. Then load-test the checkout on staging; an old WooCommerce issue (#14541) documents duplicate orders under load.
Pre-launch checklist
- Mobile LCP under 2.5 seconds on a product and a category page in PageSpeed Insights.
- Checkout tested with the provider's test cards, then one small live order you refund.
- In a private window, logged in as a test customer, the cart you see is yours.
- Selling to consumers in the EU? Since 19 June 2026, Directive (EU) 2023/2673 requires a "withdraw from contract here" function on the site. WooCommerce 11.1 added one: switch on "Order withdrawal" under WooCommerce > Settings > Advanced > Features. The form sits under
/my-account/, which your page cache already skips. wp redis statussays Connected, and nothing is past due in Scheduled Actions.- Order emails land in Gmail and Outlook inboxes, through an SMTP relay on port 587 or your own mail server. Outbound port 25 is closed on a new RS Computers server until you ask us on Telegram.
- Two-factor login on for every admin and shop manager.
- A backup copied off the server and restored once into a scratch database.
ufw statusshows only 22, 80 and 443 open.- For PrestaShop, the
installfolder gone.
Frequently asked questions
Is a VPS good for WooCommerce?
Yes, once the store takes regular orders. A VPS gives WooCommerce PHP workers and a database of its own, plus Redis and a real cron job, which shared hosting rarely allows. In return, updates and backups become your job.
How much RAM does a WooCommerce store need?
WooCommerce publishes no server size, only a PHP memory limit of at least 256 MB. Our guidance: 2 GB for a small new store with Redis and a page cache, 4 GB as the comfortable start, and 8 GB or more for busy stores and big sales.
Do I need PCI compliance if I use Stripe or PayPal?
Yes, but much less of it when the card is entered on the provider's hosted page or hosted fields, which usually means SAQ A, the shortest questionnaire. If the provider's card form is embedded in your checkout, you also confirm since 31 March 2025 that your site is not open to script attacks, so keep third-party scripts on checkout to a minimum.
How often should I back up an online store?
Daily for the database once orders come in, and right before every update. The free weekly backups RS Computers includes are the outer safety net; keep your own dumps off the server too, since a full restore rolls back every later order.
Can RS Computers set this up for me?
Yes. Message us on Telegram or email info@rscomputers-ks.com with the platform you want and the orders you expect, and we will suggest a plan and quote the setup.
Choosing your shop's plan and location
Pick a plan on the VPS and VDS plans page: VPS Micro for a small new shop, VPS Mini if you want room from day one, a VDS when a big sale is coming, in the location closest to most of your buyers. Then run the nine steps and the checklist before launch. Once orders arrive, an n8n workflow can take each new order from there, creating the invoice and posting it to your warehouse chat on Telegram.