How to Run a SaaS Product on Hong Kong VPS: Architecture and Deployment Guide 2026

Launching a SaaS product on a Hong Kong VPS gives Asia-Pacific founders and development teams a cost-effective, fully controlled infrastructure foundation — with CN2 GIA routing for low-latency access from mainland China, flat-rate billing that keeps infrastructure costs predictable at early stage, and full server control to deploy any tech stack the product requires.

This guide covers the architectural decisions specific to SaaS deployments: multi-tenant data isolation, subdomain routing per customer, subscription billing integration, feature flagging, and the scaling path from first customer to thousands of tenants — all on a Hong Kong VPS.

SaaS Architecture Fundamentals: Multi-Tenancy Models

The first architectural decision in a SaaS product is how to isolate data between customers (tenants). Three patterns exist, with different trade-offs:

Model A: Shared database, shared schema (row-level isolation)

All tenants share one database and one schema. A tenant_id column in every table identifies which tenant owns each row. Queries filter by tenant_id at the application layer.

• Pros: Lowest infrastructure cost, simplest deployment, easiest to maintain schema migrations
• Cons: One miscoded query can expose cross-tenant data; no per-tenant performance isolation; harder to offer data export per customer
• Best for: Early-stage products, low-security-sensitivity verticals, cost-constrained teams

Model B: Shared database, separate schemas (schema-level isolation)

All tenants share one database server but each gets their own schema (PostgreSQL) or database (MySQL). No cross-tenant data risk from query errors.

• Pros: Strong data isolation, still manageable at moderate tenant counts, easy per-tenant backup
• Cons: Schema migrations must run against all tenant schemas; connection pool management more complex
• Best for: B2B SaaS with compliance requirements, mid-stage products

Model C: Separate database per tenant (full isolation)

Each tenant gets a completely separate database instance — either on the same server (different port/socket) or on separate VPS instances.

• Pros: Maximum isolation, easy per-tenant scaling and migration, enterprise sales-friendly (“your data is fully separate”)
• Cons: High resource cost at scale, complex operational overhead
• Best for: Enterprise SaaS, high-compliance verticals (healthcare, finance), premium tier offerings

Recommendation for most early-stage Asia-Pacific SaaS: Start with Model A (shared schema). Implement clean tenant_id filtering from day one. Migrate to Model B when a significant enterprise customer requires data isolation or compliance mandates it.

Subdomain Routing: Giving Each Customer Their Own URL

Most B2B SaaS products use subdomain routing — each customer accesses the product at customer.yoursaas.com rather than yoursaas.com/customer. This requires wildcard DNS and Nginx routing configuration.

Step 1: Configure wildcard DNS

In your DNS provider, add a wildcard A record:

*.yoursaas.com  →  YOUR_VPS_IP  (TTL: 300)

This routes all subdomain requests to your Hong Kong VPS.

Step 2: Obtain a wildcard SSL certificate

# Certbot wildcard certificate requires DNS challenge (not HTTP)
certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d yoursaas.com \
  -d "*.yoursaas.com" \
  --email your@email.com \
  --agree-tos

Follow the prompts to add a TXT record to your DNS to verify domain ownership. For automated renewal, use a DNS provider with Certbot plugin support (Cloudflare, Route53, etc.):

# Example with Cloudflare plugin
pip install certbot-dns-cloudflare --break-system-packages
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.cloudflare.ini \
  -d yoursaas.com -d "*.yoursaas.com"

Step 3: Configure Nginx wildcard subdomain routing

nano /etc/nginx/sites-available/yoursaas.com

server {
    listen 80;
    server_name yoursaas.com *.yoursaas.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name yoursaas.com *.yoursaas.com;

    ssl_certificate /etc/letsencrypt/live/yoursaas.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yoursaas.com/privkey.pem;

    # Pass the subdomain to the application as a header
    # Your app reads this to identify the tenant
    proxy_set_header X-Tenant-Subdomain $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $host;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
    }
}

Step 4: Tenant resolution in your application

Node.js / Express example:

app.use((req, res, next) => {
  const host = req.headers['x-tenant-subdomain'] || req.hostname;
  const subdomain = host.split('.')[0];

  // Look up tenant by subdomain
  const tenant = await Tenant.findOne({ subdomain });
  if (!tenant) return res.status(404).send('Tenant not found');

  req.tenant = tenant;
  next();
});

Subscription Billing Integration

For Asia-Pacific SaaS targeting both international and Chinese customers, billing integration needs to handle multiple payment methods:

Stripe (international cards + link)

npm install stripe

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

// Create customer and subscription
const customer = await stripe.customers.create({
  email: user.email,
  metadata: { tenant_id: tenant.id }
});

const subscription = await stripe.subscriptions.create({
  customer: customer.id,
  items: [{ price: process.env.STRIPE_PRICE_ID_MONTHLY }],
  trial_period_days: 14
});

// Handle webhook for payment events
app.post('/webhooks/stripe', express.raw({type: 'application/json'}), (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET
  );

  if (event.type === 'invoice.payment_succeeded') {
    await activateSubscription(event.data.object.customer);
  }
  if (event.type === 'invoice.payment_failed') {
    await suspendSubscription(event.data.object.customer);
  }
  res.json({received: true});
});

For Chinese customers: Alipay via Stripe

Stripe supports Alipay as a payment method — Chinese customers can pay with Alipay while your billing infrastructure remains unified on Stripe. Enable Alipay in your Stripe Dashboard → Payment Methods → Alipay, then add it to your payment intent:

const paymentIntent = await stripe.paymentIntents.create({
  amount: 2000,
  currency: 'usd',
  payment_method_types: ['card', 'alipay'],
});

Feature Flags and Plan Enforcement

SaaS products need to enforce plan limits and feature availability per tenant. A simple Redis-backed feature flag implementation:

// Feature flag middleware
async function requireFeature(featureName) {
  return async (req, res, next) => {
    const tenant = req.tenant;
    const planFeatures = await redis.get(`plan:${tenant.plan}:features`);
    const features = JSON.parse(planFeatures);

    if (!features.includes(featureName)) {
      return res.status(403).json({
        error: 'Feature not available on your plan',
        upgrade_url: `https://${tenant.subdomain}.yoursaas.com/upgrade`
      });
    }
    next();
  };
}

// Usage in routes
app.post('/api/export', requireFeature('data_export'), exportHandler);
app.get('/api/advanced-reports', requireFeature('advanced_reports'), reportsHandler);

Database Migration Strategy for Multi-Tenant Schema

# Using db-migrate (Node.js) or Alembic (Python) for tenant migrations
# Run migrations across all tenant schemas

# Node.js example with Knex
const tenants = await db('tenants').select('id', 'db_schema');

for (const tenant of tenants) {
  await knex.raw(`SET search_path TO ${tenant.db_schema}`);
  await knex.migrate.latest();
  console.log(`Migrated schema: ${tenant.db_schema}`);
}

Scaling Path from VPS to Multi-Server

Conclusion

A Hong Kong VPS is an excellent foundation for an Asia-Pacific SaaS product from launch through to thousands of tenants. The combination of CN2 GIA routing for Chinese users, flat-rate billing for predictable costs, and full control over the multi-tenant architecture gives founders the infrastructure flexibility needed in early and growth stages without hyperscaler complexity.

Start your SaaS infrastructure on Server.HK’s Hong Kong VPS plans — KVM virtualisation, NVMe SSD, and CN2 GIA routing as standard.

Frequently Asked Questions

Which multi-tenancy model is best for a compliance-sensitive B2B SaaS in Asia?

For compliance-sensitive verticals (fintech, healthcare, legal), Model B (shared database, separate schemas per tenant) provides strong data isolation with manageable operational overhead. Full database-per-tenant (Model C) is only necessary when enterprise customers contractually require physical infrastructure separation or when regional data residency regulations mandate it.

How do I handle tenant data backups in a multi-tenant SaaS on VPS?

For Model A (shared schema), back up the entire database daily. For Model B (separate schemas), you can back up per-schema — enabling per-tenant restore without affecting other tenants. Use automated daily backups with restic or mysqldump to object storage (Cloudflare R2 or S3-compatible). Verify restores monthly by restoring to a test environment.

Can a single Hong Kong VPS handle 1,000 SaaS tenants?

Yes, with Model A (shared schema) and proper caching. 1,000 low-activity tenants generating intermittent requests consume far less resource than 1,000 simultaneous heavy users. Monitor actual CPU and RAM utilisation — most SaaS products with 1,000 tenants have a small fraction active at any given moment, making single-VPS operation practical through this scale.