E-commerce hosting

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.

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.

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.

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.

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.