Webshop hosting depends on how the shop is built, and there are only three ways. A hosted platform includes the hosting and you cannot change it. A WordPress shop needs WordPress hosting with more memory and a real database than a blog does. A custom or headless storefront needs an app host, a database and object storage, priced as three things. Pick the architecture first, and the hosting question mostly answers itself; the non-negotiables, HTTPS, backups, uptime and keeping card data off your server, are the same for all three.
The pages that rank for this search are hosting vendors selling web hosting with the word ecommerce added, and a couple of enterprise commerce platforms listing themselves as the best options. Neither tells a person with a small shop what the shop actually needs. That is the gap this post fills: the requirements, by architecture, then the cost.
Table of contents
- The three ways a shop is built
- The non-negotiables, whatever the architecture
- Hosting a WooCommerce shop
- Hosting a custom or headless storefront
- Performance is a conversion number
- What a small shop costs to run
- How this fits the rest of the stack
- FAQ
The three ways a shop is built
Every online shop is one of three things, and the hosting conversation is different for each.
A hosted platform. Shopify, Squarespace, Wix and their peers. The shop, the checkout and the hosting are one product on one bill. You do not choose a host because there is no host to choose; you choose a plan. The trade is control: the theme, the checkout and the data live inside the platform, and leaving means rebuilding. The Shopify vs WordPress post is about that trade.
WordPress with WooCommerce. The most common self-hosted shop on the internet. You own the site and the data, you choose a host, and the host has to be sized for a shop rather than a blog. The plugin ecosystem does everything and costs something for most of it.
A custom or headless storefront. A frontend built in Next.js or similar, a commerce backend that provides the catalogue and cart through an API, and a checkout handled by a payment provider. The most flexible and the most parts; the headless ecommerce post has the architecture and the bill.
If you have not built the shop yet, decide the architecture on who will run it. A hosted platform for someone who will never touch code. WooCommerce for someone who wants ownership and a large plugin market. Headless for a team with developers and a reason to need it. The hosting follows.
The non-negotiables, whatever the architecture
Four things are required for any shop that takes orders, and a host that makes any of them hard is the wrong host.
- HTTPS everywhere, automatically renewed. A shop is the one site where a certificate warning ends the visit. The certificate should be issued and renewed by the host without a calendar reminder.
- Backups you have restored once. Orders, customers and the product catalogue are the business. Nightly backups are the minimum; a backup nobody has tested restoring is a hope, not a backup.
- Uptime that survives a promotion. A shop’s traffic is spiky by design: a newsletter, a sale, a mention somewhere. The host needs headroom or the ability to add it quickly, because the moment the site falls over is the moment it was earning.
- Card data never on your server. Use a payment provider’s hosted checkout or their embedded fields, so the card number goes from the customer’s browser to the provider and your server never sees it. That keeps you in the lightest PCI category and removes the worst possible breach from the list of things that can happen to you.
A fifth is close to required: a staging copy of the shop, so a theme update or a plugin update is tested somewhere that is not taking orders.
Hosting a WooCommerce shop
WooCommerce is WordPress with a shop on top, and the shop changes what the host has to provide in three ways.
Memory. A blog with a caching plugin serves most pages from cache and barely touches PHP. A shop cannot cache the cart, the checkout or a logged-in account page, so every one of those requests runs PHP and hits the database. Plan for at least 1GB of memory for the site, and more if the plugin list is long, because WooCommerce plus a page builder plus a dozen extensions is a heavy PHP process.
The database. Orders and customer records are rows that must not be lost, and a busy shop’s database grows and gets queried in ways a blog’s never is. It should be a real managed database with backups and a connection limit you can read, not a MySQL process sharing the box.
Uploads. Product images are the bulk of a shop’s disk. Media should be on storage that persists across deploys and is served with cache headers, or the site will be slow on the pages that sell.
On RunxBuild, managed WordPress has its own plan ladder, and a shop belongs above the entry plans: the $13 Biz plan (1 vCPU, 1GB) is the floor for a WooCommerce site with a modest catalogue, and the $22 Medium plan (1 vCPU, 2GB) is the comfortable choice once the plugin list grows. The plans include a file manager and a database browser in the dashboard, so the theme file that broke checkout and the order row that a plugin mangled are both reachable without SFTP or phpMyAdmin. The managed WordPress post covers what managed means beyond that, and the WordPress docs cover the deploy.
Hosting a custom or headless storefront
A headless shop is three services, and the host has to be good at all three or you end up with three hosts.
The storefront. A Next.js, Nuxt or similar frontend. If it is statically generated with client-side cart and checkout, it is a static site and the cheapest possible thing to host, served from a CDN with 120GB of bandwidth included on RunxBuild and $0.10 per gigabyte after. If it renders on the server for personalised pages or a large catalogue with frequent price changes, it is a web service on a plan with enough memory for the render.
The commerce backend. Either a hosted commerce API you pay per month, in which case there is nothing to host, or an open-source commerce engine you run yourself as a Node or Docker service with a Postgres behind it. The self-hosted route is a web service plus a managed database, and the database is the part to size generously.
Storage and media. Product images and downloadable goods go in object storage with a CDN in front, never on the app server’s disk.
The reason to do this is flexibility: the storefront can be anything, the checkout can be swapped, the catalogue can feed a mobile app from the same API. The reason not to is that it is three things to run, and a small shop rarely needs it. The WooCommerce alternatives post is honest about which problems headless solves and which it invents.
Performance is a conversion number
A slow shop loses orders, measurably. The pages that need to be fast are the ones a caching plugin cannot help with: category pages with filters, the product page with its gallery, the cart and the checkout.
Three things move the number more than any hosting upgrade. Images. Product photos should be served in a modern format at the displayed size, with lazy loading below the fold. A gallery of 3MB originals is the most common reason a shop is slow. Plugins. On WooCommerce, every plugin adds PHP on every uncached request; audit the list quarterly and delete what the shop does not use. The database. Order and session tables grow; index the ones the theme queries, and clear expired sessions.
Then the hosting: a plan with enough memory that PHP is not swapping, a database on its own instance, and a CDN for the static half. Autoscaling, where the host offers it, turns the promotion-day spike from an outage into a larger bill for an afternoon, which is the correct outcome.
What a small shop costs to run
Size a shop for the busiest week, not the average one, because the busiest week is the one that pays for the year.
A WooCommerce shop with a few hundred products and modest traffic: the $22 Medium WordPress plan on RunxBuild, a domain, and a payment provider’s per-transaction fee. Add the premium plugins the shop actually uses, which is usually the largest line and the one people forget to budget.
A static storefront with a hosted commerce API: static hosting with bandwidth included, the commerce API’s monthly plan, and the payment fee. The hosting is close to nothing; the API subscription is the bill.
A self-hosted headless shop: a web service for the storefront on the $13 BasicMini plan, the commerce engine on the $20 BasicPlus plan, a managed Postgres on the $13 BasicMini plan, and object storage for media. Around $46 a month before storage and bandwidth, and every component can autoscale for the sale week.
Whichever it is, the payment provider’s percentage of every order is the largest cost of running a shop, and the hosting is a rounding error next to it once orders arrive. That is a reason to spend the hosting money on headroom rather than on the cheapest plan.
How this fits the rest of the stack
Choose the architecture by who runs the shop, then host it for the busiest week: HTTPS handled, backups tested, card data never on your server, memory and a real database sized for uncached checkout pages. For a sense of what the shop costs before it commits, the RunxBuild hosting calculator shows the WordPress plan or the storefront, database and storage as separate line items, so the hosting number sits next to the payment fee and the plugin subscriptions rather than being the only number you priced.
Useful related references:
- Shopify vs WordPress: One Bundles the Work, the Other Bundles the Choice
- Headless Ecommerce: The Architecture, and the Bill Attached to It
- Managed WordPress: What the Word Managed Actually Covers, Who It Is For, and What It Should Cost
- Managed WordPress on RunxBuild
- Static Sites on RunxBuild
FAQ
What hosting do I need for a webshop?
It depends on how the shop is built. A hosted platform includes its own hosting. A WooCommerce shop needs WordPress hosting with at least 1GB of memory and a managed database, because cart and checkout pages cannot be cached. A custom storefront needs an app host, a database and object storage. All three need automatic HTTPS, tested backups and a payment provider that keeps card data off your server.
Is shared hosting good enough for an online shop?
For a shop that takes real orders, usually not. Shared hosting is sized for cached pages, and a shop’s cart, checkout and account pages are uncached PHP and database work. The first promotion that sends traffic will find the limit. A managed WordPress plan with a gigabyte or two of memory and a separate database is the realistic floor.
Do I need to be PCI compliant to run a webshop?
Yes, but the level depends on how you take payments. Using a payment provider’s hosted checkout or embedded card fields means the card number never touches your server, which puts you in the lightest self-assessment category. Handling card data yourself moves you into a far heavier regime and is not worth it for any small shop.
How much memory does a WooCommerce site need?
Plan for 1GB as the floor and 2GB as comfortable. WooCommerce with a theme, a page builder and a dozen extensions is a heavy PHP process, and every uncached request runs all of it. If the shop slows down during a sale or PHP starts hitting its memory limit in the logs, the plan is too small.
Should I use headless commerce for a small shop?
Rarely. Headless gives a development team flexibility over the storefront and the ability to serve multiple channels from one catalogue, at the cost of running three services instead of one. A small shop with one website and no developers is better served by a hosted platform or WooCommerce, and can move to headless later if a real reason appears.