Vietnam VPS for cross-border e-commerce with China

An order lands in your store at 23:40 and the payment webhook fires from a Guangzhou buyer. Your storefront sits on a Vietnam VPS, your warehouse feed sits in Shenzhen, and the whole flow is only as stable as the box in the middle. This guide sizes and configures a Vietnam e-commerce VPS for cross-border operations with China, on Debian 12 with root or sudo, and shows you how to verify each step instead of hoping.

• Keep the database and order queue on local NVMe; never mount a database over the international link.
• 2 vCPU / 4 GB handles a starter store; move to 8 GB plus Redis queue workers once checkout traffic spikes.
• Latency to China varies by carrier and by hour, so measure it yourself with mtr before you sign anything.

越南 VPS 提供本地 IPv4，适合面向越南用户的业务。

A Vietnam VPS gives you a local IPv4, which suits services aimed at users inside Vietnam.

Why a Vietnam e-commerce VPS sits in the China cross-border chain

A cross-border store with China is really three systems talking to each other: the storefront that Vietnamese and Chinese buyers hit, the payment and logistics webhooks coming back from Chinese gateways, and the operations tooling your team runs. If that middle layer lives in Singapore or the US, every webhook pays an extra hop and every admin login feels slow.

Putting the storefront on local infrastructure means Vietnamese customers resolve to a nearby IP, the domestic leg is fast, and you keep one dedicated IPv4 from the Vietnam range instead of sharing a polluted address. That IP matters more than people admit: it is what a payment gateway allowlists and what your SMTP relay authenticates as. This is also where a Linux VPS with full root beats a shared panel, because you control the stack the webhooks hit.

Be clear about the trade-off. Anything leaving Vietnam crosses international transit, and a Vietnam VPS is local infrastructure for work that touches Vietnam. If most of your traffic is Chinese buyers, the far end of that path matters as much as your box. Size for the Vietnamese and gateway-facing part, then measure the China leg before you promise anyone a number.

Prerequisites

• A VPS running Debian 12 with NVMe storage and a dedicated IPv4 located in Vietnam.
• Root or sudo access, plus an SSH key you already use.
• A domain whose DNS you can edit, for the storefront and webhook endpoints.
• Comfort with the shell, systemd and Docker Compose v2 (docker compose, not the old hyphenated form).

Step 1 - Verify the hardware actually matches the plan

Before you install anything, confirm what you rented. Providers oversell and mislabel; a store that quietly got SATA instead of NVMe will fall over on the first sale event.

sudo apt update && sudo apt install -y fio sysstat
lsblk -d -o NAME,ROTA,SIZE,MODEL
cat /proc/cpuinfo | grep -m1 "model name"
free -m

ROTA at 0 means a real SSD/NVMe device; 1 means spinning disk. Then measure the disk with a short fio run rather than a one-shot dd that lies because of page cache.

sudo fio --name=randwrite --ioengine=libaio --direct=1 \
  --rw=randwrite --bs=4k --iodepth=32 --size=1G --runtime=30 --group_reporting

VERIFY: read the write: IOPS line. An NVMe-backed VPS lands well into the tens of thousands of IOPS at 4K; anything under a few thousand is a storage problem you should raise before migration day. If the numbers look wrong, iostat -x 1 while your store runs will show the real story under load.

Step 2 - Harden and lock the box before it takes traffic

A storefront IP gets scanned within hours of going live. Do the boring part first: key-only SSH, a non-root admin user, and a firewall that only allows what you need.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo systemctl enable --now fail2ban

Then confirm the ruleset rather than assuming:

sudo ufw status verbose
sudo ss -tlnp | grep -E ':22|:80|:443'

VERIFY: ufw status shows Status: active with only the three ports open, and ss lists a listener per port. Keep SSH on a key, not a password, and test the key in a second terminal before you close the first one. Nothing hurts a launch weekend like locking yourself out of the box that processes orders.

Step 3 - Install the runtime for the store and its workers

Most cross-border stacks here are Node.js or PHP. On Debian 12, install Node from the NodeSource repository so you get a current LTS rather than Debian's older package, then bring up Docker for the surrounding services.

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs
node -v && npm -v
sudo apt install -y docker.io docker-compose-plugin
sudo systemctl enable --now docker
sudo usermod -aG docker $USER

Log out and back in so the group change applies, then verify Docker talks to the daemon without sudo. Bring your store up with Compose v2 and pin image versions in compose.yaml; floating tags are how a random Tuesday breaks checkout.

docker compose up -d
docker compose ps

VERIFY: node -v reports a current LTS, and docker compose ps shows every service running or healthy. If a service keeps restarting, docker compose logs --tail=50 <service> tells you why in seconds.

Step 4 - Keep the database on local NVMe, never across the link

This is the mistake that kills cross-border stores. Someone mounts object storage or a remote DB over the international path, and every checkout writes across a link that fluctuates with the hour. The database belongs on the VPS's own NVMe, with a replica or a backup going elsewhere, not the write path.

sudo apt install -y postgresql
sudo systemctl enable --now postgresql
sudo -u postgres psql -c "SHOW data_directory;"

For order queues and sessions, add Redis rather than hammering PostgreSQL with polling:

sudo apt install -y redis-server
sudo sed -i 's/^# maxmemory .*/maxmemory 512mb/' /etc/redis/redis.conf
sudo systemctl restart redis-server
redis-cli info memory | grep used_memory_human

VERIFY: psql -c "SHOW data_directory" returns a path on the local volume, and redis-cli info memory shows a sensible footprint. Setting maxmemory and an eviction policy keeps Redis from eating the box your store actually needs.

Step 5 - Measure the path to China instead of believing a spec sheet

You cannot pick a provider by reading a bandwidth line. Rent for a month, run mtr from your VPS toward a target inside China during peak hours, and watch which carrier hop the packets take. Routing quality changes by provider and by time of day, and it changes again abruptly during cable incidents that hit Vietnamese international capacity.

mtr --report --report-cycles 20 <your-china-endpoint>
ping -c 10 <your-china-endpoint>
curl -o /dev/null -s -w "connect: %{time_connect}s  total: %{time_total}s\n" https://<your-china-endpoint>

Run the same test at 09:00 and at 21:00 local time. The gap between them is the number that matters, because that is when your Chinese buyers are actually placing orders. If the second-hop latency to China is unstable on your provider's default route, a small WireGuard tunnel between the Vietnam box and a relay near the border is often the fix, and you can route only the webhook traffic through it.

Step 6 - Wire the cross-border order flow and verify it end to end

Now connect the pieces: the storefront receives the order, the payment and logistics webhooks from the Chinese side hit your endpoint, and a worker pushes the fulfillment update back. Keep webhook handling asynchronous, so a slow gateway response never blocks a checkout page.

sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo nginx -t

Terminate TLS at nginx, proxy to your app container, and log every webhook body with a timestamp so you can replay a failed one. For heavier automation, an n8n VPS alongside the storefront is a clean way to keep order-sync workflows out of the web process.

curl -I https://shop.example.vn
ss -tlnp | grep :443
journalctl -u nginx --since "10 min ago" | tail -20

VERIFY: curl -I returns HTTP/2 200 with a valid certificate, and a test order from a Chinese test account lands in your database with a matching webhook log entry. If the webhook arrives but the order does not, the problem is almost always the async worker, not the network. Check supervisorctl or docker compose ps for the worker's state.

Troubleshooting common cross-border failures

When something breaks, check the layer closest to Vietnam first. The domestic leg is the part you control; treat international variance as a known variable and design around it with retries, queues and idempotent handlers.

FAQ

Related articles

• WireGuard vs OpenVPN for stable China VPS access
• Vietnam China e-commerce hosting and payment infrastructure
• Self host n8n on an Ubuntu VPS with a Vietnam IPv4
• Vietnam VPS vs offshore VPS for local traffic