What a VPS Actually Is, and Who Needs One
A Virtual Private Server sits between cheap shared hosting and an expensive dedicated machine. You get your own slice of a physical server — your own operating system, your own root access, your own resources — but you share the underlying hardware with other tenants.
That trade-off is why VPS hosting is the default choice for a huge range of Singapore businesses. It’s affordable enough for a small team, but capable enough to run a real production workload.
A VPS makes sense when:
- You’ve outgrown shared hosting and its noisy-neighbour problems
- You need root access to install software, tune a web server, or run Docker
- You’re hosting client websites, email, or internal applications
- You want predictable monthly costs rather than unpredictable cloud bills
- You need a machine you fully control, without buying hardware
And it doesn’t make sense when you’re running a brochure site that gets fifty visitors a month — shared hosting will do — or when you need bare-metal performance for heavy databases, where a dedicated server wins.
The Three Things That Actually Matter
Most VPS comparisons fixate on the wrong numbers. Look past the vCPU count and focus on these.
1. Virtualisation type — why KVM matters
This is the single most important thing to check, and almost nobody asks about it.
There are two ways to build a “VPS”:
- Container-based (OpenVZ, LXC) — you share the host’s kernel. You get what looks like a server, but you can’t change the kernel, load modules, or run Docker properly.
- Hardware-based (KVM) — you get a genuine virtual machine with its own kernel. Everything works: custom kernels, kernel modules, Docker, Kubernetes, WireGuard, nested virtualisation.
Ask your provider directly: KVM or containers? If they dodge the question, that’s your answer.
The practical difference is enormous. On a container VPS you cannot:
- Install a different Linux distribution than the host runs
- Load a kernel module you need
- Run Docker reliably for anything non-trivial
- Run a VPN with a custom protocol
- Upgrade the kernel for security patches on your own schedule
KVM costs the provider a little more to run. It costs you a lot less in frustration.
2. Where your data physically sits
Singapore is a small country, and latency to the rest of the region is geographically fixed. But “Singapore hosting” can still mean three quite different things:
- A datacentre in Singapore — lowest latency to local users and to regional traffic
- A Singapore billing address on a datacentre in Frankfurt — cheap, but 150ms+ away
- A CDN in front of a server somewhere else — fine for static content, useless for databases
If your users are in Singapore, Malaysia, Indonesia, or Vietnam, a local datacentre matters. For a database-backed application, the difference between 5ms and 160ms is the difference between snappy and unusable.
3. The traffic allowance, in writing
Traffic is where VPS bills surprise people. Look carefully at:
- How much is included — 1TB? 5TB? 30TB?
- What happens when you exceed it — billed per GB, throttled, or service suspended?
- Whether inbound counts — some providers bill it, most don’t
- Whether it’s pooled across your servers or per-server
For most Singapore workloads — a busy website, an email server, a small app — you’ll never approach a generous allowance. But if you’re hosting video, running backups to an external target, or serving large files, the traffic terms are as important as the price.
VPS vs Shared Hosting vs Dedicated
| Shared Hosting | VPS | Dedicated Server | |
|---|---|---|---|
| Control | None — provider manages | Full root | Full root |
| Resources | Shared, contended | Guaranteed slice | Entire machine |
| Scalability | Fixed plan | Upgrade in minutes | Fixed until you re-provision |
| Cost/month (SG) | S$5–20 | S$10–140 | S$150–500+ |
| Best for | Brochure sites | Most production workloads | Heavy DBs, big storage |
| Isolation | Weak | Strong (with KVM) | Complete |
The gap between shared and VPS is mostly about isolation and control. The gap between VPS and dedicated is mostly about cost and scale.
What a VPS Costs in Singapore
Market rates for VPS in Singapore, looking at well-provisioned KVM plans:
- Entry (4 vCPU / 6–8 GB / 100 GB) — around S$10–15/month. Enough for a small site, a mail server, or a staging environment.
- Mid (8 vCPU / 24 GB / 300 GB) — around S$25–35/month. The sweet spot for a small business running several services.
- High (12–16 vCPU / 48–64 GB / 400–500 GB) — around S$50–80/month. Handles production databases, busy multi-site hosting, CI runners.
- Large (24 vCPU / 120 GB / 600 GB) — around S$140/month. Near the top of what a “VPS” classifies as.
Two notes on this. First, Singapore pricing runs noticeably higher than European datacentres — commonly 50–60% more for identical specs. That’s space, power, and connectivity costs, not markup. Second, prices exclude GST, and are usually on 1-month terms unless you commit longer for a discount.
If a Singapore VPS looks dramatically cheaper than these ranges, check what’s missing: it’s often a container VPS rather than KVM, a datacentre that isn’t actually in Singapore, or a traffic allowance that’s far smaller than advertised.
Latency: Why the Datacentre Location Matters
Rough round-trip latency from Singapore, by destination:
- Singapore → Singapore datacentre — 1–5ms
- Singapore → Hong Kong — 30–40ms
- Singapore → Tokyo — 65–80ms
- Singapore → Frankfurt / London — 150–180ms
- Singapore → US East — 200–240ms
This is physics as much as networking — distance and the speed of light, plus routing. No amount of money makes Frankfurt as fast as Singapore for a Singapore audience.
What this means practically:
- Databases must be close to the application. Cross-region database calls are the most common cause of a “slow” app.
- Static assets tolerate distance — put a CDN in front and geography stops mattering.
- Batch and backup jobs can be anywhere. Overnight syncs don’t care about 160ms.
A sensible architecture for a Singapore business: everything interactive in Singapore, static content on a CDN, backups replicated offshore.
Compliance: PDPA and Where Your Data Lives
If you handle personal data, Singapore’s PDPA applies. It doesn’t require data to stay in Singapore — but it does require you to be accountable for it, which means knowing:
- Where your data is stored and processed
- Who can access it, including your provider’s staff
- How it’s protected in transit and at rest
- What happens to it if you terminate the service
Practical questions to ask any VPS provider:
- Which country is the datacentre in — and do you have it in writing?
- Do you take backups, where do they live, and how long are they retained?
- What’s your policy on law-enforcement requests for customer data?
- Can I get a data processing agreement?
For regulated industries — finance, healthcare, legal — a Singapore datacentre simplifies this considerably, and having the answers documented is often the difference between passing and failing an audit.
A 10-Minute Check When Your VPS Goes Live
Before you deploy anything, confirm you got what you paid for. This takes ten minutes and settles every claim in the sales page.
#!/bin/bash
# First-10-minutes VPS check. Run as root on a fresh server.
echo "=== 1. Virtualisation type ==="
systemd-detect-virt
# 'kvm' = true hardware virtualisation (what you want)
# 'lxc' or 'openvz' = container — you got less than you paid for
echo; echo "=== 2. Nested virtualisation available? ==="
ls -l /dev/kvm 2>/dev/null && echo " /dev/kvm present" \
|| echo " no /dev/kvm (fine on a VPS, relevant only for VMs-in-VM)"
echo; echo "=== 3. CPU ==="
lscpu | grep -E "Model name|^CPU\(s\)|MHz|Hypervisor"
echo; echo "=== 4. Memory ==="
free -h
echo; echo "=== 5. Disk layout and free space ==="
df -hT / /var 2>/dev/null
echo; echo "=== 6. Sequential disk throughput ==="
dd if=/dev/zero of=/tmp/bench bs=1M count=1024 oflag=direct 2>&1 | tail -1
rm -f /tmp/bench
echo; echo "=== 7. Network ==="
ping -c 3 1.1.1.1 | tail -2
echo; echo "=== 8. Geographically where am I? ==="
curl -s https://ipinfo.io/json | grep -E '"city"|"country"|"org"'
How to read the results:
| Check | Good result | Bad result |
|---|---|---|
systemd-detect-virt | kvm | lxc, openvz |
lscpu Hypervisor | KVM | absent or odd |
dd throughput | 300+ MB/s | under 100 MB/s |
ipinfo.io city | your expected city | a surprise |
free -h | matches the plan | less than advertised |
That last one is worth emphasising — check that free -h and df -h match the plan you bought. Occasionally they don’t.
Then lock the box down:
# Create a non-root user and give it sudo
adduser deploy
usermod -aG sudo deploy
# Move your SSH key across
mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh && chmod 600 /home/deploy/.ssh/authorized_keys
# Harden SSH: no root login, no password auth
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh
# Enable automatic security updates
apt update && apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades
Verify you can still log in as deploy before you close your current session — otherwise you’ve locked yourself out.
Migrating from Shared Hosting Without Downtime
The standard approach, in order:
- Build the new server and harden it using the steps above
- Install your stack and copy your site or application across
- Test via hosts-file override — point your own machine at the new IP and check everything works, without touching DNS
- Lower your DNS TTL to 300 seconds at least a day beforehand
- Take a fresh backup of the old server immediately before the switch
- Repoint DNS, then watch both servers for 48 hours
- Decommission the old one a week later, once you’re confident
The TTL step is the one people skip, and it’s the one that makes the cutover painless. Drop it a day early and the switch propagates in minutes instead of hours.
What to Look For in a VPS Provider
Beyond the spec sheet, these are the things that decide whether you’re happy in month six:
- Answers about virtualisation — KVM, stated plainly
- A real datacentre location, not a billing address
- Snapshot support — a rollback point before you make a risky change
- Backup options that live off the machine — snapshots on the same host aren’t backups
- Object storage for off-box backups and archives
- Console access — so a broken firewall rule doesn’t mean a support ticket and a wait
- Explicit traffic terms in writing
- A human you can reach — which matters more than any spec when something breaks at 2am
That last point is where local providers usually beat hyperscalers. An AWS bill comes with documentation; a local provider comes with someone who knows your setup.
Two Ways This Goes: A Worked Example
Same business, same budget, two decisions.
The bad choice. A 12-person design studio in Singapore signs up for a S$9/month VPS that turns out to be container-based, hosted in Frankfurt, with 1TB of traffic. It works fine for their portfolio site — until they add a client portal with a database. Page loads sit at 1.8 seconds because every query makes a 160ms round trip, and when they try to install Docker for a staging environment, it fails. They migrate to a proper Singapore VPS eight months later, having spent the difference twice over in lost hours.
The good choice. A similar studio buys a mid-tier KVM VPS in a Singapore datacentre for around S$30/month, with NVMe storage and 5TB of traffic. They run the day-one checks, confirm systemd-detect-virt returns kvm, and see database queries complete locally in a few milliseconds. When they add a staging environment, Docker works on the first try. Their only later change is resizing the plan when traffic grows — a five-minute operation.
The difference wasn’t budget. It was asking three questions before signing up: KVM or containers? Which datacentre? How much traffic?
Common Mistakes
Choosing on price alone. The cheapest VPS is often a container VPS in a datacentre nowhere near Singapore.
Skipping the virtualisation question. If it’s not KVM, half the things you’ll want to do are off the table.
Not testing disk performance. vCPU and RAM get compared constantly; disk I/O is what makes a database feel slow.
Leaving root login and password auth enabled. Most compromised VPSes were never targeted — they were found by a scanner because SSH was left open.
Treating snapshots as backups. They live on the same hardware. If the host dies, you lose both.
Ignoring the traffic terms until an invoice arrives.
Over-provisioning at the start. Buy the mid tier, watch real usage for a month, then resize. VPS plans are easy to change.
The Bottom Line
Choosing a VPS in Singapore comes down to four questions: Is it genuinely KVM? Is the datacentre actually in Singapore? What are the traffic terms? And can I reach a human when something breaks?
Get those right and the spec sheet is mostly a matter of matching size to workload — start mid-tier, measure, resize. Get them wrong and you’ll be migrating again within a year.
Vastspace provides KVM-based virtual private servers in Singapore with NVMe storage, snapshots, object storage for off-box backups, and console access — as part of the same hosting, email, and infrastructure stack we’ve run since 2016.