Many developers and operations personnel encounter the same problem during business expansion: they only have one server, but need to support multiple businesses simultaneously—multiple websites, multiple API services, multiple proxy nodes… Buying a new server is too costly, but not buying one risks resource conflicts and management chaos.

Actually, deploying multiple nodes on a single server isn't complicated. The key is choosing the right solution and rationally planning resources. This tutorial will systematically outline three mainstream multi-node deployment solutions, from the simplest port differentiation to the most flexible containerized isolation; there's bound to be one that suits your needs.

Why deploy multiple nodes on a single server?

Before we begin, let's clarify one question: Why deploy multiple nodes on a single server instead of buying multiple machines?

The answer is simple—a balance between cost and efficiency.

A high-configuration dedicated server or cloud server (e.g., 8 cores, 16GB RAM, 100Mbps bandwidth) often has computing resources far exceeding the demands of a single business. Instead of letting most of the CPU and memory sit idle, it's better to deploy multiple nodes on the same machine to fully utilize the resources.

For cross-border e-commerce businesses, SaaS entrepreneurs, and technology teams, the core value of single-machine multi-node deployment lies in:

- Cost savings: A single high-spec server is typically more cost-effective than multiple low-spec servers.

- Unified management: All nodes reside on a single machine, resulting in more centralized and efficient operations and maintenance.

- Flexible scalability: Nodes can be added as needed, with resources dynamically allocated.

Of course, single-machine multi-node deployment also carries the risks of resource contention and single points of failure. However, through proper resource isolation and monitoring, these issues can be effectively controlled within acceptable limits.

Solution 1: Port Differentiation Method – The Most Basic and Direct

Applicable Scenarios: A small number of nodes (3-5), independent business processes, and low isolation requirements.

Core Idea: Running multiple service instances on the same server, distinguishing different nodes using different port numbers.

Operation Steps

Step 1: Port Planning

Assume you want to deploy 3 web service nodes on a server:

Node Name Service Port Purpose

Node A 8080 Cross-border e-commerce main site

Node B 8081 Foreign trade inquiry system

Node C 8082 Management backend

Step 2: Deploy the service on each node separately

Taking Nginx as an example, you can create multiple configuration files under `/etc/nginx/sites-available/`:

Node A Configuration

server {

listen 8080;

server_name example.com;

root /var/www/site_a;

}

Node B Configuration

server {

listen 8081;

server_name api.example.com;

root /var/www/site_b;

}

Each node runs independently and does not interfere with the others.

Step 3: Use Nginx Reverse Proxy for a Unified Entry Point (Optional)

If you don't want users to remember different port numbers, you can use Nginx as a reverse proxy + path forwarding:

nginx

server {

listen 80;

server_name example.com;

location /site-a/ {

proxy_pass http://127.0.0.1:8080/;

}

location /site-b/ {

proxy_pass http://127.0.0.1:8081/;

}

}

This way, users can access different nodes through `example.com/site-a/` and `example.com/site-b/`, providing a similar experience to accessing different servers.

Advantages and Disadvantages

Advantages | Disadvantages

Simple configuration, quick to learn | Port management is chaotic, prone to conflicts with many nodes

No additional software required | Poor isolation, a single node failure may affect the entire system

Low resource overhead | Difficult to implement resource quota limits

Solution Two: Docker Containerization – Most Flexible and Mainstream

Suitable Scenarios: Large number of nodes, requiring environment isolation, and pursuing standardized deployment.

Core Idea: Encapsulate each node as an independent Docker container. Each container has its own file system, network stack, and process space, without interference.

Operation Steps

Step 1: Install Docker

Ubuntu/Debian

apt-get update

apt-get install docker.io docker-compose -y

CentOS

yum install docker docker-compose -y

Start the Docker service

systemctl start docker

systemctl enable docker

Step 2: Write a Dockerfile for each node

Assuming you want to deploy 3 API nodes based on Node.js:

Dockerfile

Dockerfile for node A

FROM node:18-alpine

WORKDIR /app

COPY package.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

Step 3: Use docker-compose for unified orchestration

Create `docker-compose.yml` in the project root directory:

yaml

version: '3'

services:

node-a:

build: ./node-a

container_name: node-a

ports:

- "8080:3000"

restart: always

environment:

- NODE_ENV=production

node-b:

build: ./node-b

container_name: node-b

ports:

- "8081:3000"

restart: always

node-c:

build: ./node-c

container_name: node-c

ports:

- "8082:3000"

restart: always

Step 4: Start all nodes

docker-compose up -d

One-click start and stop of all nodes, extremely efficient management.

Advanced: Limiting Resource Quotas for Each Node

Docker supports CPU and memory limits to prevent a single node from consuming excessive resources and affecting other nodes:

yaml

services:

node-a:

deploy:

resources:

limits:

cpus: '0.5'

memory: 512M

reservations:

cpus: '0.25'

memory: 256M

Advantages and Disadvantages

Advantages: Environment isolation, no interference; requires learning Docker; resource quota limits; server kernel version requirements; extremely convenient deployment, rollback, and scaling; slightly larger disk footprint than direct deployment; industry standard, well-developed ecosystem.

Solution 3: K3s Lightweight Kubernetes – The Most Professional and Powerful

Suitable Scenarios: Large number of nodes (10+), requiring cluster-level management, pursuing high availability and automatic scaling.

Core idea: Deploy K3s (lightweight Kubernetes) on a single server, leveraging Kubernetes' Pod and Service mechanisms to manage multiple nodes.

Steps

Step 1: Install K3s

K3s is a lightweight Kubernetes distribution from Rancher, ideal for deployment on a single VPS:

curl -sfL https://get.k3s.io | sh -

After installation, K3s will automatically configure the `kubectl` command-line tool.

Step 2: Create Multiple Deployments

Create a Deployment configuration file for each node:

yaml

node-a-deployment.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: node-a

spec:

replicas: 1

selector:

matchLabels:

app: node-a

template:

metadata:

labels:

app: node-a

spec:

containers:

- name: app

image: your-image:latest

ports:

- containerPort: 3000

---

apiVersion: v1

kind: Service

metadata:

name: node-a-service

spec:

selector:

app: node-a

ports:

- protocol: TCP

port: 80

targetPort: 3000

type: ClusterIP

Step 3: Deploy all nodes

kubectl apply -f node-a-deployment.yaml

kubectl apply -f node-b-deployment.yaml

kubectl apply -f node-c-deployment.yaml

Step 4: Use Ingress for unified routing

Forward requests from different domains to the corresponding Services through the Ingress controller:

yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: main-ingress

spec:

rules:

- host: site-a.example.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: node-a-service

port:

number: 80

- host: site-b.example.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: node-b-service

port:

number: 80

Advantages and Disadvantages

Advantages Disadvantages

Enterprise-level container orchestration capabilities Steep learning curve

Automatic health checks and restarts Single-machine K3s deployment incurs certain resource overhead

Supports rolling updates and rollbacks High server configuration requirements

Seamlessly scales to multi-machine clusters —

Comparison of Three Solutions and Selection Recommendations

Comparison Dimensions Port Differentiation Method Docker Containerization K3s/Kubernetes

Learning Cost ⭐ Very Low ⭐⭐ Medium ⭐⭐⭐⭐ High

Resource Overhead ⭐ Lowest ⭐⭐ Medium ⭐⭐⭐ High

Isolation ⭐ Poor ⭐⭐⭐⭐ Good ⭐⭐⭐⭐⭐ Excellent

Management Efficiency ⭐⭐ Average ⭐⭐⭐⭐ High ⭐⭐⭐⭐⭐ Extremely High

Scalability ⭐ Poor ⭐⭐⭐ Good ⭐⭐⭐⭐⭐ Excellent

Suitable for 3-5 5-20 10+ Nodes

Selection Recommendations:

- Beginners/Few Nodes (≤5): Port-based deployment, simple and sufficient.

- Intermediate/Medium Nodes (5-20): Docker containerization, highest cost-effectiveness.

- Enterprise/Many Nodes (10+): K3s/Kubernetes, professional and reliable.

Considerations for Single-Machine Multi-Node Deployment

1. Resource Planning in Advance

A server's CPU, memory, disk, and bandwidth are all limited. Before deploying multiple nodes, calculate the costs:

- How much CPU and memory does each node need?

- Does the total resource requirement of all nodes exceed the total server resources?

- Is the bandwidth sufficient to support the traffic of all nodes?

It is recommended to reserve 20%-30% of resources as a margin to handle sudden traffic surges.

2. Avoid Port Conflicts

When using port-based deployment, be sure to create a port planning table to avoid two nodes competing for the same port. It is recommended to use high-end ports in the 8000-9000 or 10000-20000 range.

3. Monitoring and Alerting are Essential

The more nodes there are, the higher the probability of problems. It is recommended to deploy Prometheus + Grafana or use the monitoring system provided by the cloud service provider to monitor the CPU, memory, disk, and network status of each node in real time.

4. Data Backup Should Be Separate

Data (databases, logs, configuration files) from different nodes should be stored in different directories to avoid accidental data overwriting.

Why Choose Jtti Cloud Servers?

Single-machine multi-node deployment places high demands on server hardware performance, network stability, and disk I/O—an inadequately configured machine may experience lag or even crash when running two or three nodes.

Jtti cloud servers are designed for this scenario:

- High-performance hardware: Equipped with Intel Xeon Gold processors and enterprise-grade NVMe SSD arrays, ensuring smooth operation even with multiple nodes running concurrently.

- Premium CN2 GIA line: Global low-latency access, providing a stable experience regardless of the region your node serves.

- Flexible configuration: Available in various configurations from 1 core 1GB to 8 cores 16GB to meet the needs of different scales of single-node systems.