# E-commerce hosting

Source: https://www.fortrabbit.com/use-cases/e-commerce-store
Created: 2026-07-20
Reviewed: 2026-07-20

> Host a PHP online store — Shopware, Lunar on Laravel, or WooCommerce. Campaign traffic spikes, persistent media storage, background order processing, and safe deploys.


Checkout must never lose a write, and a deployment must never take the shop down with it. Shopware, Lunar on Laravel, and WooCommerce all run on PHP because the ecosystem around payments, tax, and shipping is deeper in this language than in the alternatives.

## Peaks are events, not growth

Store traffic answers to campaigns rather than to a trend line. A newsletter goes out, a piece gets shared, or it's the last Friday in November, and the peak is 10 or 20 times the median for a few hours. Scaling the PHP component up for a campaign and back down afterwards is a normal operation, billed pro-rated by the day.

## Orders finish after the request does

Payment capture, stock sync, invoice generation, and feeds to an ERP or a marketplace belong in the jobs component rather than in a request handler. Worker jobs drain the queue, cron jobs run the scheduled syncs, and both are restarted after every deployment so they always run the latest code. A store built that way absorbs a burst in the queue and works through it afterwards.

Card data belongs with the payment provider, not on the shop's own host. What the store does keep — addresses, order history, e-mail — lives in MySQL with the backup component behind it.

## FAQ

### Can the platform handle a Black Friday spike?

**With planning** — Campaign peaks are predictable, which is the useful part. Each component scales on its own: the PHP plan is raised in the dashboard for the days that need it and lowered afterwards, while traffic, storage, and MySQL can autoscale with usage. Each day is billed at 1/30th of the monthly rate, so a week of extra capacity costs a week, not a month.

### Where do product images and customer uploads go?

**Persistent storage** — On the web storage of the environment, which is persistent. Product media, generated thumbnails, and invoice PDFs written at runtime stay where they are — the default merge deployment strategy syncs new code in without deleting runtime files. Storage autoscales as the catalog grows, and the backup component snapshots it daily. No S3 bucket required.

### Where does card data live in a hosted shop?

**With the payment provider** — Not on the shop's own host. Modern checkouts hand the card off to Stripe, Mollie, Adyen, or PayPal through a hosted field or a redirect, so the store only ever holds order records and tokens. A configuration that puts card numbers on the application host moves the compliance burden onto the merchant, which is the wrong place for it.

### Can a live store be deployed to without an outage?

**Mostly** — A Git push runs the build — Composer, asset bundling — in a separate deploy container, not on the live host, and only the finished package is synced into the web space. The risk that remains is the application's own: database migrations in the post-deploy commands and cache warm-up. Both are worth rehearsing on a staging environment before they meet a live checkout.

### Can the storefront show live stock or order updates?

**No** — Persistent connections are not supported, so anything that pushes updates into an open page is out of scope. Stock levels refresh on page load or by polling on a sensible interval, which is how most storefronts work in any case.

---

- [Backups](/features/backups)
- [Scale on demand](/benefits/scale-on-demand)
- [Jobs](/features/jobs)