Ecommerce Hosting
A store that stays
fast at checkout
Browsing pages come from cache. Cart and checkout never do, so these plans are sized for the pages that actually take the money.
- Free migration from any host
- Renewal price shown upfront
Sized by orders, not storage
A cart and a checkout cannot be cached the way a blog post can, so these plans are measured by the work a store actually creates. Redis and LSCache for WooCommerce are configured on every one.
- Redis object cache
- LSCache tuned for WooCommerce
- Free managed migration
- Renewal price shown upfront
Prices in USD, before any applicable tax. Product figures are a comfortable working size, not a hard limit — tell us what you are running and we will say honestly which plan fits.
Performance
Fast enough to pass the test
Google scores real visitors on three Core Web Vitals and uses the result in ranking. Here is each scale — and whether your host can actually move it.
Largest Contentful Paint
How long the main content takes to appear.
Hosting helps
NVMe storage and LiteSpeed with LSCache, on every plan.
Interaction to Next Paint
How quickly the page responds to a click or tap.
Hosting helps
Isolated resources, so a busy neighbour never slows your site.
Cumulative Layout Shift
Whether content jumps around while the page loads.
Your theme decides
Set by your theme and how images are sized. No host changes it, so we will not claim to.
GoodNeeds improvementPoorThresholds as published by Google.
What changes when you start selling
Hosting written for content sites makes assumptions that quietly stop being true the moment there is a checkout. These are the five that matter most.
Every page can be served from cache
Cart, checkout and account pages must be generated fresh for each visitor
Caching a checkout would show one customer another's basket. So the busiest, most valuable pages get no help from the cache at all.
Traffic is fairly steady
A campaign email can multiply traffic within minutes
Capacity that comfortably handles a Tuesday can fail at eight o'clock on launch night, which is precisely when failing costs the most.
The database is read almost exclusively
Every order writes to several tables at once
Writes cannot be spread across replicas the way reads can, so database performance becomes the ceiling long before bandwidth does.
Downtime costs attention
Downtime costs orders that do not come back
A reader returns tomorrow. A customer with a full basket buys somewhere else and does not think about it again.
Sessions barely matter
Sessions hold the basket, the login and the checkout state
Session storage has to be fast and reliable, which is why we keep it in memory rather than on disk on plans that need it.
The checkout gets the attention, because that is where sales are lost
A slow product page is annoying. A slow checkout is an abandoned basket. Everything below exists to keep the last three clicks fast when everything else is under load.
- Cache exclusionsSet before you arrive
Cart, checkout, my-account and any endpoint carrying a session are excluded automatically, so a customer never sees another customer's basket.
- Session storageIn memory, not on disk
Baskets and login state are held in Redis, which means the checkout does not slow down as the number of active shoppers rises.
- PHP workersAllocated, not shared
Uncached requests need a worker each. Yours are reserved, so a queue on another store cannot leave your customers waiting.
- DatabaseTuned for write load
Order tables receive concurrent writes during a rush. Buffer sizes and connection limits are set for that pattern rather than for a read-heavy blog.
- Catalogue deliveryCached and served from the edge
Product pages and images are the part that can be cached, and they are — which frees capacity for the pages that cannot be.
- Admin performanceKept separate from the storefront
Running a bulk import should not slow down the shop. Admin requests are given their own headroom so the two do not compete.
The busiest hour of your year should not be a surprise to your host
Most hosting is passive: it holds up or it does not, and you find out at the same time your customers do. For a store, the predictable spikes are the ones worth preparing for together.
Tell us the date
A sale, a product drop, a campaign email going to fifty thousand people. Two weeks of notice is plenty, and a day is better than nothing.
We look at your numbers
Current worker usage, database load and cache hit rate, measured rather than guessed. That tells us where the ceiling actually is.
Capacity goes up beforehand
Workers and memory are raised ahead of the event, not while it is happening. Scaling under load is the worst time to try it.
We watch it with you
During the window, someone is looking at the graphs. If something starts to strain, we act before your customers notice.
No surprise invoice
Temporary capacity for a planned event is quoted before it is applied, and it comes back down afterwards. We have no interest in a store paying year-round for one weekend in November.
Payment data never touches our servers
Card details go straight from the customer to your payment provider. Your store never stores or transmits them, which keeps the compliance burden where it belongs.
PCI-friendly infrastructure
TLS everywhere, current PHP versions, isolated accounts and no shared database users. We can supply what your provider asks for during a compliance review.
Backups that include the orders
A store backup is worthless if it restores the catalogue but loses yesterday's orders. Database and files are captured together, so a restore is coherent.
Vulnerability monitoring on plugins
Ecommerce plugins are a common route in. Yours are checked against published advisories daily, and we patch or warn rather than waiting for something to happen.
Firewall rules written for stores
Rate limits on login and checkout endpoints, card-testing patterns blocked, and bot traffic filtered before it reaches PHP and consumes a worker.
Malware cleanup included
If something does get in, removing it is part of your plan. A compromised store is an emergency, and we do not treat emergencies as a billing opportunity.
Before you move your store
Questions store owners ask first
If something is not covered here, ask before you buy. We would rather answer honestly than have you switch hosts again in three months.