If most of your customers live in Australia, ecommerce hosting in Australia is less about prestige and more about physics. Every product page, cart update and checkout step is a round trip between the shopper and your server, and a store hosted on another continent adds that distance to every click. This guide walks through what an online store actually needs from a Sydney VPS: how to size it for WooCommerce or Magento, how to cache without breaking carts, and where a local server stops being the deciding factor.
Why local hosting matters for Australian shoppers
A store is not a brochure site. A blog can be cached almost entirely at a CDN, but a shop has dynamic pages that cannot be: the cart, the checkout, account pages, stock checks and payment callbacks. Those requests go to your origin server every time. When the origin sits in Sydney, shoppers in Sydney, Melbourne and Brisbane reach it over a short domestic path instead of a trans-Pacific or Asian route.
Local hosting also keeps things simple when you think about where customer data lives. You still need to follow Australian privacy rules and your payment processor's requirements, but having the database in the same country as your customers is an easier story to tell than explaining a server abroad.
Cloudj runs cloud servers in Sydney; the Australia VPS page lists the plans, and monthly plans there include 1 TB of traffic. If you are still comparing countries in the region, the Americas, Oceania and Israel VPS guide covers how Sydney fits next to the other locations, and best VPS in Australia goes deeper on the location itself.
Ecommerce hosting Australia checklist: what the store needs
Before you pick a plan, write down what the server will run. A typical self-hosted store has more moving parts than people expect:
- Web server and PHP: Nginx or Apache with PHP-FPM. The number of PHP workers you can run is limited by RAM.
- Database: MySQL or MariaDB. Product catalogues with many variations and order history grow faster than you think.
- Object cache: Redis, to keep repeated database queries out of MySQL.
- Search: Magento 2 requires a search engine (OpenSearch) as part of the stack. WooCommerce can work without one, but large catalogues often add one later.
- Background jobs: WP-Cron or a real system cron for WooCommerce; cron and queue consumers for Magento.
- Email: order confirmations should go through a proper transactional email service rather than straight from the VPS, so they land in inboxes.
Each of these competes for the same CPU and memory, which is why sizing matters.
Sizing WooCommerce and Magento
Cloudj's Sydney location offers 30 ready-made plans, from 1 vCPU with 1 GB RAM and 20 GB disk up to custom sizes of 104 vCPU and 512 GB RAM, and you can build your own mix of vCPU, RAM and disk. The console shows the exact price for each size before you deploy, and live prices are on the pricing page.
A rough way to think about it:
| Store profile | Starting point | What usually runs out first |
|---|---|---|
| New WooCommerce store, small catalogue | 2 vCPU, 4 GB RAM | PHP workers during a sale |
| Established WooCommerce store, steady orders | 4 vCPU, 8 GB RAM | Database memory, slow admin |
| Magento 2 with OpenSearch on one server | 4 vCPU, 8 GB RAM or more | RAM, because OpenSearch and PHP both want it |
| Seasonal peaks (EOFY, Black Friday, Christmas) | Resize up for the event | CPU on uncached checkout requests |
These are starting points, not promises. Watch the CPU, RAM and network graphs in the console for a couple of weeks and adjust. You can resize CPU and RAM and grow the disk later, so it is reasonable to start modestly; the resize guide explains what changes and what needs a reboot.
On CPU type: shared ("Availability") CPU is fine for a small store, general purpose suits most established shops, and dedicated cores make sense when checkout performance must stay steady under load, for example a store that runs heavy promotions. The trade-offs are covered in shared vs dedicated CPU VPS.
Caching that does not break the cart
Caching is where most of the speed comes from, and where most store bugs come from too. Use three layers:
- OPcache for PHP. It is usually enabled by default; make sure
opcache.memory_consumptionis large enough for your plugins or extensions. - Redis object cache to cut repeated database queries. Install it with
sudo apt install redis-serveron Ubuntu or Debian and connect WooCommerce through an object cache plugin, or point Magento's cache and session configuration at it. - Full-page cache for anonymous visitors on catalogue pages.
The full-page cache must skip anything personal. For WooCommerce, bypass the cache for /cart/, /checkout/ and /my-account/, and for any request carrying the woocommerce_items_in_cart or wp_woocommerce_session_ cookies. A minimal Nginx FastCGI cache rule looks like this:
set $skip_cache 0;
if ($request_method = POST) { set $skip_cache 1; }
if ($request_uri ~* "/(cart|checkout|my-account)/") { set $skip_cache 1; }
if ($http_cookie ~* "woocommerce_items_in_cart|wp_woocommerce_session_|wordpress_logged_in") { set $skip_cache 1; }
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;Magento 2 has its own full-page cache built in and documents Varnish as the recommended backend; enable it in production mode rather than building a custom rule.
After you set this up, test as a real shopper: add a product to the cart in a private window, then load the home page and check the cart count. If it shows zero, your cache is serving a shared copy to a logged-in session.
Security and backups for a store
A store holds customer details and order history, so treat the server accordingly. Start with SSH keys, a firewall that only opens ports 22, 80 and 443, and automatic security updates; the new VPS security checklist has the full list. Never store raw card numbers on the server; let your payment processor handle card data.
For backups, dump the database on a schedule and copy the dumps off the server. You can also save your own custom image of a configured server from the console, which is handy before a major plugin or Magento upgrade. The VPS backup strategy guide explains how to combine both.
When a Sydney VPS is not the right choice
Be honest about your audience. If a large share of orders come from Europe or North America, a single Sydney server makes them wait instead. In that case put the origin closer to the majority and use a CDN for static assets, or look at regional guides such as ecommerce hosting in Spain and Italy. The same logic of putting the server near the people who matter drives other workloads too, from forex VPS in London to forex VPS in New York.
If you sell mainly to customers in Vietnam, Sydney is not the nearest location either. Cloudj has no servers in Vietnam; the WordPress VPS guide for Vietnamese websites explains how to choose between Singapore, Hong Kong and Tokyo.
And if you would rather not manage a server at all, a hosted store platform may suit you better. A VPS gives you control and room to grow, but someone has to patch it.
FAQ
Is 1 TB of monthly traffic enough for an online store?
For most small and medium stores, yes, especially once images are served through a CDN. Check the network graph in the console after a busy month to see how close you are.
Can I start small and upgrade before a big sale?
Yes. You can resize CPU and RAM and grow the disk from the console. Plan the resize ahead of the event and test the store afterwards.
Should I choose hourly or monthly billing for a store?
A production store runs all month, so a prepaid monthly term with included traffic is usually simpler. Hourly billing suits short-lived staging copies.
Can I pay from Vietnam or in another currency?
You top up a USD account balance. Customers in Vietnam can also top up by bank transfer in VND.
Getting started
Pick a Sydney plan that fits your store profile, deploy it in the Cloudj console, and move your store across when caching and backups are in place. If you are migrating an existing shop, the website migration guide walks through a low-downtime switch. Live prices for every size are on the pricing page.