SSD VPS in Australia

Distance is the whole argument for a server in Australia

Most of the world's websites are hosted in Europe, North America or Asia, which is a long way from Sydney. Every request from an Australian visitor to a server on another continent has to cross a great deal of ocean, and distance and the number of network hops both affect response time. A server in the same country or region as your visitors usually responds faster than one on another continent. For Australia that gap is bigger than for most places, which is why an Australian VPS is easier to justify than a local server would be in Germany. If you are weighing Australia VPS hosting against a cheaper server abroad, that distance is the thing to price in.

We are not going to put a number on it. Real figures depend on the visitor's internet provider and the route on the day. But you can feel the difference on pages that make many small requests: a shop with dozens of product images, a dashboard that polls the server every few seconds, a login form that talks to an API before it lets anybody in. Those are the pages that benefit when the server sits in Sydney, Australia's biggest city.

A CDN helps with static files, and it is worth adding to any busy site. It cannot make a dynamic request cheaper, though. The origin still answers searches, baskets and API calls, so if your customers are Australian and your origin is in another hemisphere, the slow part stays slow.

This page is for people with a clear Australian audience: a local business, an agency with Australian clients, a SaaS product for Australian and New Zealand customers, or a team that needs a development server near its own staff. If you are mostly serving people elsewhere, another of our locations will probably suit you better, and the datacentres page shows them all.

The price in the plan cards above is live for the datacentre you choose. It may include a location surcharge for Sydney, and it excludes GST. SSD VPS is delivered within 2-3 days.

Sydney time, daylight saving and working hours with India

Time zones matter more than people expect when a server and its owner are far apart, and Sydney has a wrinkle: daylight saving. Sydney is UTC+10, or UTC+11 during daylight saving, which runs roughly from October to April. India stays on UTC+5:30 all year. That means Sydney is four and a half hours ahead of India for part of the year and five and a half hours ahead for the rest.

So the overlap is real but short: an Indian morning meets a Sydney afternoon. If you are an Indian developer serving Australian customers, expect to reply to late-day emails from Sydney at the start of your own morning, and to do maintenance at the end of yours.

What about support?

Our support is available 24x7 in English, Hindi and Marathi, so you are never waiting for a particular shift to begin. The overlap question is really about your own people. Decide who is on call during the Sydney business day, and write that down before the first incident.

Daylight saving and your cron jobs

The easiest way to avoid clock confusion is to keep the server on UTC. Scheduled jobs then run at the same moment all year, and you convert for humans in the application. If you really want local time, remember that a job set for 02:30 may run twice or not at all on the night the clocks change.

Trading peaks and what people actually host in Sydney

Australian traffic has a calendar of its own. Two dates dominate the shop owners we talk to: the end of the financial year on 30 June, when discounting and last-minute purchasing collide, and Boxing Day, when shoppers hunt for bargains. Those are the days when a store that is fine on a quiet Tuesday finds out how much headroom it really has. Seasonal pushes are easier to survive when you have a tested plan and a snapshot to return to.

Retail and online shops

A WooCommerce or custom-built store with steady orders belongs on Cloud VPS 8 or above. Memory goes first: 24 GB gives the database room to cache and the PHP workers room to breathe. Run a load test a week before a sale, and remember that a CDN trims image traffic but not the checkout itself.

Agencies and local service businesses

A Sydney agency with a dozen client websites can start on Cloud VPS 8 or 12, with every client in a separate system account. It is a reasonable home for clients who want VPS hosting Australia based, without paying for a dedicated machine.

Business applications

Booking systems, quoting tools, small CRMs and internal portals fit on Cloud VPS 6. They are not heavy, but their users are in Australian office hours, so a server that answers promptly makes the whole tool feel better.

Teams working across time zones

A shared development or staging server for engineers in Sydney and Pune fits on Cloud VPS 4 or 6. Keep deployment automated so a release never depends on whoever happens to be awake.

Services that must stay up while you sleep

A bot, a webhook receiver, a scheduler. The systemd example further down shows how to make sure they restart themselves.

Choosing a Cloud VPS size for Sydney: a short ladder

Work up from the smallest plan and stop when the next step stops making sense. The SSD VPS Australia range has six sizes, and storage on every plan is SSD. Each plan includes full root access, snapshots, DDoS protection and traffic that is unlimited subject to fair use.

1. Cloud VPS 4 (4 vCPU, 8 GB RAM, 100 GB SSD, upgradable, 200 Mbit/s port). Starter sites, development and staging. If you only need to try your code in Australia first, begin here.
2. Cloud VPS 6 (6 vCPU, 12 GB, 200 GB, 300 Mbit/s). Growing sites and small apps. The first plan where a web server and a modest database coexist without fighting.
3. Cloud VPS 8 (8 vCPU, 24 GB, 300 GB, 600 Mbit/s). Busy stores, APIs and databases. This is where we would put a business that depends on the site for its income.
4. Cloud VPS 12 (12 vCPU, 48 GB, 400 GB, 800 Mbit/s). Heavy apps and many projects. Good for agencies and for databases that like a large buffer.
5. Cloud VPS 16 (16 vCPU, 64 GB, 500 GB, 1 Gbit/s). Large workloads and resellers.
6. Cloud VPS 18 (18 vCPU, 96 GB, 600 GB, 1 Gbit/s). Maximum memory for big stacks.

Two honest limits. A single VPS is a single machine, and if its host has a problem, everything on it goes with it. If your business cannot tolerate that, plan a second server and a tested restore. And if you outgrow even Cloud VPS 18, the dedicated servers in Sydney give you a whole physical machine to yourself.

Extras you can add at checkout are Windows Server, daily backups and a bigger disk. The base plans leave daily backups out, so decide on that before you order, not after.

SSD here, NVMe VPS and other options in Sydney

This page is for the SSD range, so storage is SSD rather than NVMe. We also run an NVMe range in Sydney, and it is a fair alternative worth looking at on its own page: NVMe VPS in Australia. Its four plans run from NVMe VPS S (2 vCPU, 4 GB RAM, 40 GB NVMe) up to NVMe VPS XL (8 vCPU, 24 GB RAM, 200 GB NVMe), with port speeds from 500 Mbps to 3 Gbps.

The rule of thumb is simple. If your workload fits inside those four sizes and leans on the disk, such as a busy database or a lot of small-file reads, look at NVMe. If you need more memory or disk than XL offers, the SSD plans on this page reach 96 GB of RAM and 600 GB of disk. Neither is better in general. They answer different problems.

Other things that live in Sydney:

• The Cloud VPS range in Australia, a different VPS product.
• The Storage VPS in Australia, when you mainly need capacity.
• The dedicated servers in Sydney, including plans aimed at gaming.

If you are still unsure whether a VPS is right for you, the shared vs VPS guide and the VPS overview are good places to compare.

Running your app as a service: systemd, logrotate and an rsync backup

A Sydney server is easy to forget about, which is exactly why it should look after itself. Here are three pieces we would set up before going to bed on day one. Examples assume Debian or Ubuntu and a Node.js application, but the pattern works for any language.

A systemd service

Create /etc/systemd/system/myapp.service:

[Unit]
Description=My application
After=network.target

[Service]
User=deploy
WorkingDirectory=/srv/myapp
ExecStart=/usr/bin/node server.js
Restart=on-failure

[Install]
WantedBy=multi-user.target

Then run sudo systemctl daemon-reload, sudo systemctl enable myapp and sudo systemctl start myapp. If the process dies, systemd brings it back, and journalctl -u myapp shows what it said before it went.

logrotate so logs do not fill the disk

Create /etc/logrotate.d/myapp:

/var/log/myapp/*.log {
    weekly
    rotate 8
    compress
    missingok
    notifempty
}

A nightly copy to a second location

A snapshot lives with the server it was taken from, so it will not save you from losing the machine. Keep a copy somewhere else, such as a server in another city or your office. Save this as /usr/local/bin/nightly-backup.sh:

#!/bin/sh
STAMP=$(date +%F)
mysqldump --single-transaction myapp | gzip > /var/backups/myapp-$STAMP.sql.gz
rsync -az -e ssh /var/backups/ [email protected]:/srv/backups/sydney/
rsync -az -e ssh /srv/myapp/uploads/ [email protected]:/srv/backups/uploads/
find /var/backups -name 'myapp-*.sql.gz' -mtime +14 -delete

Schedule it with a crontab line such as 30 2 * * * /usr/local/bin/nightly-backup.sh, give mysqldump its credentials through a protected options file, and restore one backup into a spare database to prove it works. If you would rather not run this yourself, daily backups are an option at checkout.

Moving your site to a Sydney VPS

If your site currently runs in India, Europe or America, moving it to Sydney is mostly a matter of order and nerve. Because delivery takes 2-3 days, you can prepare while you wait.

Begin with an inventory. List every moving part: web server, application runtime and version, database, scheduled jobs, mail settings, TLS certificates and third-party integrations such as payment gateways that may whitelist your server address. Missing one of those is the usual reason for a failed cutover.

Next, build the new server from that list and copy a first version of the data across. Lower your DNS TTL a few days before the switch. On the night, put the old site in maintenance mode, take a final database dump, restore it in Sydney, sync the last uploaded files and update DNS. Keep the old server running for a week so you can roll back by pointing DNS at it again.

Test from an Australian vantage point if you can. Ask a colleague in Sydney to load key pages, log in, and place a test order. Compare how it feels with the old setup, because the whole reason you moved was to improve it for those visitors. If something is slower, it is more likely a database query or an unoptimised image than the server location, and it is better to find that out now.

Prefer help? The managed support service can take on admin tasks, and our team is reachable through the contact page.

The Privacy Act and your Australian server

This is general information, not legal advice, so please check with your own adviser. Australia's Privacy Act 1988 and the Australian Privacy Principles cover how personal information is collected, used and disclosed. They include rules on disclosing personal information overseas, and the Notifiable Data Breaches scheme sets out what to do when a breach is likely to cause serious harm.

Putting a server in Sydney does not by itself make a business compliant. What matters is how you treat the information: what you collect, who sees it, what you tell people and how you respond when something goes wrong. A local server can make conversations with Australian clients easier, and can simplify questions about where data sits, but it is one small input.

Think about where copies travel. If your backup script sends customer records to a server in another country, or you use an analytics or support tool that stores data abroad, that may be the kind of overseas disclosure the Privacy Principles talk about. That is a question for your adviser rather than for us. A useful habit is to keep a short list of every place personal data goes, because the same list helps you answer customer questions and respond quickly if you ever need to notify anyone of a breach.