Every page on a blog can be cached and served in milliseconds. A store cannot do that — carts, checkouts and account pages have to be generated fresh, for every visitor, every time. Hosting built for one behaves badly for the other.
Storage is cheap. The work of processing an order is not, so plans are sized by the thing that actually costs.
Cart, checkout and account pages are excluded automatically, so sessions and totals behave correctly.
Tell us when the campaign runs and we look at capacity beforehand rather than reacting on the day.
Disk space is the cheapest thing in hosting and the least useful way to size a store. These plans are measured by the work a store actually creates.
A first store, or a shop attached to an existing site.
Rs2,499/mo
Save 29%
Billed Rs 29,988 for 12 months
Renews at Rs 3,499/mo
A working store with steady daily orders and a growing catalogue.
Rs5,999/mo
Save 25%
Billed Rs 71,988 for 12 months
Renews at Rs 7,999/mo
Sale events, flash traffic and a catalogue that does not stay still.
Rs13,499/mo
Save 25%
Billed Rs 161,988 for 12 months
Renews at Rs 17,999/mo
Multi-store operations and catalogues measured in hundreds of thousands.
Rs33,749/mo
Save 25%
Billed Rs 404,988 for 12 months
Renews at Rs 44,999/mo
Prices in PKR, exclusive of applicable taxes. Order limits are guidance rather than hard caps — we talk to you before anything is throttled or upgraded.
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.
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.
Cart, checkout, my-account and any endpoint carrying a session are excluded automatically, so a customer never sees another customer's basket.
Baskets and login state are held in Redis, which means the checkout does not slow down as the number of active shoppers rises.
Uncached requests need a worker each. Yours are reserved, so a queue on another store cannot leave your customers waiting.
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.
Product pages and images are the part that can be cached, and they are — which frees capacity for the pages that cannot be.
Running a bulk import should not slow down the shop. Admin requests are given their own headroom so the two do not compete.
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.
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.
Current worker usage, database load and cache hit rate, measured rather than guessed. That tells us where the ceiling actually is.
Workers and memory are raised ahead of the event, not while it is happening. Scaling under load is the worst time to try it.
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.
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.
TLS everywhere, current PHP versions, isolated accounts and no shared database users. We can supply what your provider asks for during a compliance review.
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.
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.
Rate limits on login and checkout endpoints, card-testing patterns blocked, and bot traffic filtered before it reaches PHP and consumes a worker.
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.
What store owners ask before switching hosts.
Sizing a server is easier with someone who has done it before. Tell us what you are running and we will suggest a size — including a smaller one, if that is the honest answer.
Ask before you buy