By Shubham Sinha in Game Hosting — 14 Jun 2026

How to Set Up a Minecraft Network in India (2026)

A Minecraft network links game servers under one proxy. This 2026 India guide covers BungeeCord vs Velocity, security risks, port setup, and hosting decisions.

Running a single Minecraft server works fine until players want more — survival today, SkyBlock tomorrow, mini-games on the weekend. The moment you want to offer more than one game mode without forcing players to disconnect and reconnect to a different IP, you need a Minecraft network. This guide explains exactly what a Minecraft network is, how the proxy layer works, which proxy to choose for an Indian setup in 2026, and what can go wrong if you skip the security steps.

Quick answer: A Minecraft network is two or more backend game servers connected behind a single proxy server. Players join one IP address and switch between servers instantly. For new networks in India, choose Velocity over BungeeCord — it is actively developed, uses a significantly faster async event pipeline, and ships with a secure forwarding protocol that BungeeCord cannot match.

What Is a Minecraft Network?

A Minecraft network is a group of individual Minecraft server instances that appear to the player as one unified service. From the player's perspective, they type a single IP address into their client and land on a lobby. From there they can teleport to a survival server, a mini-games hub, a creative world, or any other game mode without quitting to the main menu.

The three-layer model looks like this:

Player Client
      |
      v
 [Proxy Server]  <-- Single public IP, port 25565
  BungeeCord or Velocity
      |
      +---> [Lobby Server]       127.0.0.1:30066
      |
      +---> [Survival Server]    127.0.0.1:30067
      |
      +---> [SkyBlock Server]    127.0.0.1:30068
      |
      +---> [Mini-games Server]  127.0.0.1:30069

The proxy receives every player connection on port 25565 (or whichever port you expose publicly). It authenticates the player with Mojang's session servers (in online-mode networks), then forwards the connection to a backend server. The backend servers run on internal ports not exposed to the internet. The player never connects to the backend directly — they always go through the proxy.

The proxy also handles cross-server transfers. When a player clicks a sign that says "Join SkyBlock," the proxy disconnects them from Survival and connects them to SkyBlock without the client seeing a disconnection screen.

Why Build a Network Instead of a Single Server?

A single well-optimised Paper server with multiple worlds covers most use cases for small communities. But once you have more than 40–50 concurrent players or want genuinely different game modes, a network architecture pays off.

Isolation: Each backend server runs in its own JVM. A memory leak in your SkyBlock plugin does not crash your Survival server. You can restart one server without affecting the others.

Scalability: You add a new game mode by spinning up a new backend server and adding two lines to the proxy config. No migration, no downtime for existing servers.

Player retention: Players stay on your network longer when switching game modes requires a command rather than an IP change. A player who is bored of survival can try a mini-game in 10 seconds instead of leaving entirely.

Resource allocation: You can tune JVM heap size per server. A creative server with 30 players needs different memory than a Factions server with the same count. Separate JVMs let you tune each independently.

Economy of scale in Indian hosting: If you are already paying for a VPS with 8 GB RAM, running three 2 GB backend servers and one 512 MB proxy on the same machine costs nothing extra compared to running a single 8 GB server.

The trade-off is complexity. You have more moving parts to monitor, more configs to keep in sync, and a new class of security problem (the IP forwarding vulnerability discussed later). For a server with fewer than 30 players and no plans for multiple game modes, a single Paper server is the right choice.

The Proxy Layer: What BungeeCord and Velocity Actually Do

Both BungeeCord and Velocity are Minecraft proxy servers. They speak the Minecraft client protocol on one side and connect to standard Minecraft server instances on the other side. Neither is a game server — they handle no world simulation, no chunk generation, no entity processing.

At the protocol level, when a client connects to the proxy:

The proxy completes the Minecraft handshake and login sequence with the client.
In online-mode, the proxy authenticates the player with Mojang's session server.
The proxy picks a backend server (usually the lobby, defined in config).
The proxy opens a separate TCP connection to the backend server.
Packets from the client are decoded by the proxy, optionally inspected or modified by plugins, and re-encoded for the backend.
Packets from the backend flow back to the client the same way.

This decode-inspect-re-encode pipeline is where the two proxies diverge fundamentally in how they handle concurrency.

BungeeCord's threading model assigns one thread per player connection pair (one for client-to-proxy, one for proxy-to-backend). At 200 concurrent players, BungeeCord is managing roughly 400 threads. Thread context switching at that scale creates CPU overhead, and BungeeCord's event system is synchronous — a slow event handler blocks the thread handling that player's packets.

Velocity's threading model uses Netty's non-blocking I/O with a fixed pool of event loop threads. Hundreds of player connections share a small number of threads. Velocity's event system is async-first — event handlers run on a dedicated scheduler thread pool, so a slow plugin handler does not stall the packet pipeline. This is why Velocity handles the same player count with lower CPU usage and more predictable latency than BungeeCord.

Velocity is faster than BungeeCord because it uses a modern async event pipeline built on Netty's non-blocking I/O, reducing per-connection thread overhead from two threads per player to a shared pool of event-loop threads.

BungeeCord vs Velocity: Head-to-Head Comparison

Feature	BungeeCord	Velocity
Threading model	One thread per connection (sync)	Shared Netty event loops (async)
Performance at scale	Degrades above ~200 players	Handles 500+ players on 1 GB RAM
Minimum Java version	Java 8 (Java 21 recommended)	Java 21 (required)
Config format	YAML (`config.yml`)	TOML (`velocity.toml`)
Player info forwarding	Legacy (BungeeCord forwarding) — insecure by default	Modern forwarding — HMAC-signed, secure
Forwarding security	IP forwarding is sent in plain text in login packet — trivially spoofable	Forwarding secret creates a MAC; backend verifies it before accepting
Active development	Maintenance mode only — mostly security patches	Actively developed by PaperMC team
Plugin ecosystem	Very large — 10+ years of plugins	Growing — most common network plugins now support Velocity
Plugin API	BungeeCord API	Velocity API (not compatible with BungeeCord plugins)
BungeeCord plugin compat	Native	Experimental via Snap plugin only
Backend compatibility	Spigot, Paper, Purpur, CraftBukkit	Paper 1.13+, Purpur, Fabric (with FabricProxy-Lite), Forge 1.14+
Minecraft version support	1.4.7 and above	1.7.2 and above (modern forwarding requires 1.13+)
Recommended by PaperMC	No — PaperMC says use Velocity	Yes
Waterfall (BungeeCord fork)	—	Waterfall is end-of-life as of 2024

Winner: Velocity, unless you have a large investment in BungeeCord-only plugins that have no Velocity equivalent.

The BungeeCord plugin ecosystem is larger simply because BungeeCord has existed since 2012. But for any network being built in 2026, the important plugins — LuckPerms, EssentialsX, Geyser, plan, RedisBungee-compatibility forks — all support Velocity. The security and performance advantages are substantial enough that starting a new network on BungeeCord in 2026 requires a specific justification.

Network Architecture for Indian Setups

Same Machine vs. Separate Machines

The most common Indian network topology for small-to-medium networks is running everything on a single VPS or dedicated server in one datacenter. This is the simplest setup and has one major advantage: proxy-to-backend latency is effectively zero (sub-1ms on loopback).

[Single VPS — Mumbai datacenter]
|
+-- Velocity proxy        (512 MB RAM, port 25565 public)
+-- Lobby server          (1 GB RAM,  port 30066 internal)
+-- Survival server       (2 GB RAM,  port 30067 internal)
+-- SkyBlock server       (2 GB RAM,  port 30068 internal)

For this topology, backend servers bind to 127.0.0.1 only. They are never reachable from the internet. The proxy binds to 0.0.0.0:25565.

Once you outgrow a single machine, you split the load across machines. The proxy stays on a small VPS (512 MB–1 GB is enough for Velocity handling 500 players). Backend servers move to separate machines or separate plans.

[Small VPS — Mumbai]           [Larger VPS — Mumbai]
Velocity proxy                 Lobby + Survival + SkyBlock
Port 25565 (public)  <-------> Port 30066, 30067, 30068
                               (private network or firewall-whitelisted)

When proxy and backend are on separate machines in the same datacenter, internal latency is typically 0.5–2ms — negligible for Minecraft. If proxy and backend are in different datacenters (e.g., proxy in Mumbai, backend in Bangalore), you add 15–30ms of inter-datacenter latency to every packet. This is noticeable. Keep your proxy and your most latency-sensitive backends in the same datacenter.

Which Indian Datacenter to Choose

Mumbai (Navi Mumbai, specifically the Equinix MB1 and similar facilities) has the best connectivity from most Indian metros. Players in Chennai, Hyderabad, and Pune typically see 20–35ms to Mumbai. Delhi NCR players see 25–40ms to Mumbai and 10–20ms to Delhi-based DCs.

The practical advice: host your proxy and primary backend servers in one location — whichever gives the best average latency to your player base. A pure Delhi audience does best in Delhi. A mixed national audience does best in Mumbai. Do not split your proxy from your backends across cities to save money — the added inter-server latency is not worth it.

Port Configuration Explained

The port model for a Minecraft network is straightforward but confuses many new admins.

External port (what players type): Port 25565 is the Minecraft default. Players connect to yourserver.in:25565 or just yourserver.in (clients try 25565 if no port is specified). Only the proxy listens on this port. Your router/firewall/VPS security group must allow inbound TCP on 25565 to the machine running the proxy.

Internal ports (backend servers): Each backend server listens on a different port that is not exposed to the internet. Common conventions:

Lobby:         127.0.0.1:30066
Survival:      127.0.0.1:30067
SkyBlock:      127.0.0.1:30068
Mini-games:    127.0.0.1:30069
Creative:      127.0.0.1:30070

You can use any free port above 1024. The proxy's config maps these. In Velocity's velocity.toml:

[servers]
lobby    = "127.0.0.1:30066"
survival = "127.0.0.1:30067"
skyblock = "127.0.0.1:30068"

try = ["lobby"]

The try list is the fallback chain: when a player joins, Velocity tries each server in order until one accepts the connection.

In each backend server's server.properties:

server-ip=127.0.0.1
server-port=30066
online-mode=false

Setting server-ip=127.0.0.1 makes the server only accept connections from the local machine. This is your first line of defense — combined with firewall rules, it ensures players cannot bypass the proxy by connecting directly to backend server ports.

Firewall rules (iptables example on Linux):

# Allow proxy port from anywhere
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

# Allow backend ports only from localhost
iptables -A INPUT -p tcp --dport 30066:30070 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30066:30070 -j DROP

If backends are on a separate machine, replace 127.0.0.1 with the proxy server's private IP.

Security: The IP Forwarding Vulnerability (Read This Carefully)

This section covers the most common way Minecraft networks in India get compromised. Understand it thoroughly before going live.

The Problem

A Minecraft network requires all backend servers to run with online-mode=false in server.properties. This is not optional — the proxy handles authentication with Mojang, and the backend must trust the proxy's assertion of player identity rather than re-authenticating with Mojang independently.

The security problem is this: any Minecraft client can connect directly to a backend server running online-mode=false using any username they choose, including _ForgeUser0, Server, or admin.

With BungeeCord's legacy IP forwarding enabled (ip_forward: true in BungeeCord's config.yml, settings.bungeecord: true in spigot.yml), the backend trusts the login packet's IP and UUID fields as forwarded by the proxy. But if someone connects directly to yourserver.in:30067 with a custom client and manually crafts a login packet claiming to be UUID: <any-admin-uuid>, the server accepts it. They are now that player, complete with all permissions.

This exact attack vector has been used to grief and wipe Indian Minecraft servers. A player who knows or guesses a backend server's port connects directly, bypasses the proxy, claims an operator's UUID, and runs /op, /stop, or world-deletion commands. The proxy's permission system, ban lists, and chat filters are completely bypassed.

BungeeCord's Legacy Forwarding — Why It Is Fundamentally Insecure

BungeeCord's player information forwarding (the IP and UUID sent to backends) is transmitted as plain-text data appended to the vanilla login handshake. There is no cryptographic verification. A custom client connecting directly to the backend can send arbitrary data in those fields. The backend cannot distinguish a legitimate connection from the proxy from a spoofed direct connection.

The BungeeGuard plugin improves this by adding a token to the forwarding data, but it is still weaker than Velocity's solution because the token must be stored in plaintext on the backend server.

Velocity's Modern Forwarding — How It Solves This

Velocity generates a random secret key stored in forwarding.secret on the proxy. This secret is also placed in config/paper-global.yml on each backend:

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "your-secret-here"

When Velocity connects to a backend, it includes a HMAC-SHA256 signature of the forwarding data (player UUID, IP, skin data) using this shared secret. The backend verifies the MAC before accepting the connection data. A client connecting directly cannot produce a valid HMAC without knowing the secret.

Velocity modern forwarding is cryptographically secure — it uses HMAC-SHA256 to sign all forwarding data so backend servers can verify the connection genuinely comes from the proxy and not a spoofed client.

This means even if a malicious player knows your backend server's port and connects directly with online-mode=false, the backend rejects any connection that does not include a valid HMAC signature matching the shared secret.

Modern forwarding requires: Minecraft 1.13 or higher on the client, and Paper 1.13+ or Purpur on the backend.

Cracked Servers and the Indian Context

A large share of Indian Minecraft servers run in offline mode (online-mode=false on the proxy itself) to allow players without a paid Mojang account to join. This is referred to as running a "cracked" server. Cracked servers are common across India because a significant portion of the player base uses unofficial copies of Minecraft.

Running the proxy in offline mode introduces additional risk: Mojang's session server never verifies player identity, so players can claim any username. Griefing via impersonation (joining as an existing player's name to frame them, or claiming an admin's username) is straightforward on cracked networks.

If you run a cracked network:

Use an anti-cheat plugin that works independently of Mojang auth (such as GrimAC or Vulcan).
Use a UUID-based permissions system (LuckPerms) rather than name-based.
Make absolutely certain backend ports are firewalled — the risk of direct backend access is higher because there is no Mojang authentication at any layer.
Consider a login plugin (AuthMe Reloaded or nLogin) to enforce per-player passwords. This is the standard approach for cracked Indian networks.

Even with Velocity's modern forwarding, a cracked proxy does not authenticate with Mojang. Modern forwarding still protects the proxy-to-backend channel — it just does not fix the fact that anyone can claim any username at the proxy level.

Step-by-Step Setup Overview

This section walks through the setup process with enough detail to give you a real mental model. It is not a copy-paste tutorial — specific version numbers change, but the sequence and logic do not.

Step 1: Install Java 21

Velocity requires Java 21 at minimum. Install Eclipse Temurin 21 (the recommended distribution) on your proxy machine:

# On Ubuntu/Debian
apt install -y wget apt-transport-https
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor -o /etc/apt/trusted.gpg.d/adoptium.gpg
echo "deb https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list
apt update
apt install -y temurin-21-jdk
java -version

Step 2: Download and Launch Velocity

Download the latest stable Velocity jar from papermc.io/downloads/velocity. Create a dedicated directory for the proxy:

mkdir ~/velocity-proxy && cd ~/velocity-proxy
wget https://api.papermc.io/v2/projects/velocity/versions/3.5.0/builds/latest/downloads/velocity-3.5.0-latest.jar -O velocity.jar

Create start.sh:

#!/bin/sh
java -Xms512M -Xmx512M \
  -XX:+UseG1GC \
  -XX:G1HeapRegionSize=4M \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+ParallelRefProcEnabled \
  -XX:+AlwaysPreTouch \
  -XX:MaxInlineLevel=15 \
  -jar velocity.jar

Run it once to generate the config files, then stop it with the end command.

Note the 512 MB heap. Velocity is a proxy, not a game server. It does not hold world data or entity state. 512 MB handles 500 concurrent players comfortably. Do not over-allocate RAM to the proxy — that memory is better spent on backend servers.

Step 3: Configure velocity.toml

The generated velocity.toml needs three things configured before going live:

# Proxy bind address and port
bind = "0.0.0.0:25565"

# Online mode — set to true for premium, false for cracked
online-mode = true

# Player info forwarding — use "modern" for Paper 1.13+ backends
player-info-forwarding-mode = "modern"

[servers]
lobby    = "127.0.0.1:30066"
survival = "127.0.0.1:30067"
skyblock = "127.0.0.1:30068"

try = ["lobby"]

[forced-hosts]
# If you use subdomains: lobby.yourserver.in = ["lobby"]

The file forwarding.secret is auto-generated with a random key. Copy its contents — you need it on every backend server.

Step 4: Configure Each Backend Server

For each Paper backend server:

server.properties:

server-ip=127.0.0.1
server-port=30066
online-mode=false

config/paper-global.yml (Paper 1.19+):

proxies:
  velocity:
    enabled: true
    online-mode: true    # Match your proxy's online-mode setting
    secret: "paste-the-contents-of-forwarding.secret-here"

Disable BungeeCord forwarding if it was previously enabled:

spigot.yml:

settings:
  bungeecord: false

Restart each backend after making these changes.

Step 5: Verify the Connection

Start your backend servers first, then start Velocity. In the Velocity console, run:

velocity dump

This prints the status of all registered backends. A working backend shows as reachable. Connect to your proxy IP from a Minecraft client — you should land on the lobby server.

Test player info forwarding by installing a plugin like LuckPerms on a backend and checking /lp user <your-name> info — the UUID shown should be your Mojang UUID (for online-mode networks), not an offline-mode UUID.

Hardware Requirements: Proxy vs. Backend

The proxy and backend servers have very different resource profiles.

Velocity proxy resource usage:

Concurrent Players	RAM (Velocity heap)	CPU
Up to 100	256 MB	Minimal — <5% of a single core
Up to 500	512 MB	Low — <15% of a single core under sustained load
500–1,000	1 GB	Moderate — scales with plugin complexity
1,000+	1–2 GB	Consider a second proxy instance with load balancing

Velocity's async architecture means the proxy itself is never the bottleneck at normal scale. It is almost always the backend game servers that reach their limits first.

Backend server resource usage follows the standard Minecraft server scaling model:

Players per Server	RAM	CPU
Up to 20	1 GB	1 core
20–50	2 GB	2 cores
50–100	4 GB	2–4 cores
100+	6–8 GB	4+ cores

For a typical Indian network with 100 concurrent players spread across three game servers (lobby, survival, skyblock), a single VPS with 8 GB RAM and 4 vCPUs in Mumbai handles the full setup: 512 MB for Velocity, 1 GB for the lobby, 3 GB each for survival and skyblock.

Essential Plugins for a Minecraft Network

Permissions: LuckPerms

LuckPerms is the standard permissions plugin for Minecraft networks. Its network feature — storing permissions in MySQL or MariaDB rather than flat files — ensures that permission changes made on one server propagate to all servers without manual copying or restarts.

Install LuckPerms on every backend server. Point all instances at the same MySQL database:

# LuckPerms config.yml (storage section)
storage-method: mysql
data:
  address: 127.0.0.1:3306
  database: luckperms
  username: luckperms_user
  password: your-password

With this configuration, running /lp user Steve permission set minecraft.command.op false on the survival server takes effect on SkyBlock immediately when Steve next performs a permission check.

Cross-Server Data Sync: MySQL/MariaDB

A shared MySQL or MariaDB database is the standard approach for any data that must be consistent across servers: player balances, statistics, ranks, playtime. Each plugin that needs cross-server state should have a MySQL storage option.

For an Indian server, run MySQL on the same machine as your backends (for single-machine setups) or on a dedicated DB server on the same private network. Avoid connecting to a remote database in a different city — the 20ms round-trip adds up when a single player action triggers multiple DB queries.

Player List Sync: RedisBungee and Forks

The classic RedisBungee plugin (and its maintained forks such as RedisBungee-Compatibility and AjQueue) uses Redis to synchronise the online player list across proxy instances. Without it, commands like /list or /msg only see players on the same backend server.

For Velocity, use a fork that explicitly supports the Velocity API, such as the Limbo-based or Lushpixel forks. The original RedisBungee targets BungeeCord only.

Redis is lightweight — 64 MB of RAM covers the needs of most networks. Run it on the same machine as the proxy.

World Management: Multiverse-Core

If individual backend servers host multiple worlds (e.g., a survival server with a main world and a separate mining world), Multiverse-Core handles per-server world management. It does not operate across the proxy — world management stays within each backend JVM.

Cross-Platform Play: Geyser

Geyser translates the Bedrock Edition protocol to Java Edition, allowing Xbox, PlayStation, mobile, and Switch players to join your Java Edition network. Geyser can run as a plugin on the Velocity proxy or as a standalone instance.

When running Geyser on Velocity, Bedrock players connect on UDP port 19132 (the Bedrock default). They appear to the backend as Java players after Geyser translates their packets. A companion plugin, Floodgate, handles Bedrock player UUIDs and prefixes to avoid username conflicts with Java players.

[Bedrock Client, UDP 19132] --> [Geyser on Velocity] --> [Backend servers]
[Java Client, TCP 25565]    --> [Velocity]            --> [Backend servers]

Geyser on a proxy is worth running if your player base includes mobile players — a significant segment in India where Minecraft Bedrock on mobile is common.

Scaling: When to Add a Second Proxy

A single Velocity instance handles 500–1,000 concurrent players comfortably. Beyond that, or if you need zero-downtime proxy restarts, you add a second proxy instance.

Two proxy instances cannot share state natively. You need:

A load balancer (HAProxy or a hardware load balancer) in front of both proxy instances, distributing TCP connections from port 25565.
Redis for cross-proxy player list synchronisation (via RedisBungee or equivalent).
Consistent backend server config — both proxies must know about all backend servers.

Player -->  [HAProxy, port 25565]
                |         |
         [Velocity 1]  [Velocity 2]
                |         |
            [Backend servers — shared]

Both Velocity instances connect to the same backend servers. Redis keeps them in sync on who is online. HAProxy distributes new connections in round-robin.

For the vast majority of Indian networks, this is far beyond what is needed. Reach 500 concurrent players on a well-optimised single-proxy setup before considering multi-proxy. The added operational complexity of dual-proxy with HAProxy and Redis is significant.

When NOT to Build a Network

Minecraft networks are not always the right answer. Build a network when you have:

Multiple distinct game modes that justify separate JVMs.
Enough players to fill more than one server simultaneously.
Enough technical capacity to maintain multiple server instances.

Do not build a network when:

You have a small friend group of 5–20 players. A single Paper server with Multiverse-Core for multiple worlds is simpler and cheaper.
Your game modes share state heavily (e.g., a prison server where everything is one economy, one world progression). Networks complicate cross-server data — what is naturally a single-server feature becomes a distributed systems problem.
You are new to Minecraft server administration. Learn single-server operations thoroughly before adding proxy complexity. Debugging "why did my player get disconnected" is harder when the answer might be in the proxy log, the backend log, a plugin on either, or a firewall rule.
Your budget is limited. The cheapest competent VPS for a network is more expensive than for a single server, because you now have minimum resource requirements for the proxy plus at least two backends.

8-Question FAQ

What is a Minecraft network proxy and why do I need one?

A Minecraft network proxy is a server-side software layer (BungeeCord or Velocity) that accepts player connections and forwards them to backend game servers. It is required because individual Minecraft servers cannot natively accept connections from players who are already connected to a different server instance.

Which is better for a new Indian Minecraft network in 2026, BungeeCord or Velocity?

Velocity is the clear choice for new networks in 2026. Velocity uses an async event pipeline that performs better at scale, ships with HMAC-signed modern forwarding that is cryptographically secure, and is actively maintained by the PaperMC team. BungeeCord is in maintenance mode and its legacy forwarding protocol has known security weaknesses.

Why do backend servers need to run with online-mode=false?

Backend servers must run with online-mode=false because the proxy handles Mojang authentication before the player reaches the backend. If a backend tried to re-authenticate with Mojang, it would reject the incoming connection from the proxy. The proxy already verified the player's identity — the backend must trust that assertion rather than re-verifying it independently.

What is the BungeeCord IP forwarding vulnerability and how does Velocity fix it?

BungeeCord's legacy forwarding sends player UUID and IP data in plain text during the login handshake with no cryptographic verification. Any client connecting directly to a backend server with online-mode=false can craft a login packet claiming any UUID, including an admin's, granting themselves elevated permissions. Velocity's modern forwarding prevents this by signing all forwarding data with HMAC-SHA256 using a shared secret — the backend rejects any connection that cannot produce a valid signature.

How much RAM does Velocity need compared to a backend server?

Velocity needs 512 MB of heap to comfortably handle 500 concurrent players — significantly less than any game server. Backend Minecraft servers need 1–4 GB per 20–100 players depending on plugin load and game mode. The proxy's lean resource profile means it can share a machine with backend servers without competing for memory.

Can I run BungeeCord or Velocity on cracked (offline-mode) servers safely?

Running a cracked network adds security risk but can be done safely with the right precautions. The proxy must run in online-mode=false, which means Mojang never verifies player identities — username spoofing is trivial. Mitigation requires: a login plugin (AuthMe, nLogin) to enforce passwords; firewall rules that prevent direct backend access; LuckPerms with MySQL for UUID-based permissions; and robust DDoS protection since cracked servers attract more unwanted traffic.

Should I host my proxy and backend servers in the same datacenter in India?

Yes. Hosting the proxy and backends in the same datacenter gives sub-millisecond proxy-to-backend latency. Splitting them across datacenters (e.g., proxy in Mumbai, backends in Bangalore) adds 15–30ms of inter-datacenter latency to every packet, which compounds for every cross-server interaction. The cost savings from splitting across DCs never justify the latency penalty.

What plugins are essential for a Minecraft network using Velocity?

LuckPerms with MySQL storage is essential for consistent permissions across servers. A shared MySQL or MariaDB database is required for any cross-server player data. Geyser on the proxy allows Bedrock (mobile, console) players to join. A Redis-backed player sync plugin is needed if running multiple proxy instances. For cracked networks, a login plugin such as AuthMe or nLogin is mandatory before opening to the public.

Conclusion

Building a Minecraft network in India in 2026 is more accessible than it has ever been. The proxy software (Velocity), the backend server (Paper), and the permission management layer (LuckPerms) are all mature, well-documented, and actively maintained. The hardware cost for a small-to-medium network on Indian infrastructure is reasonable.

The two decisions that matter most are the proxy choice and the security model. Velocity is the right proxy choice for any new network — its async architecture, modern forwarding, and active development make it objectively better than BungeeCord for anything built today. The security model — firewall rules blocking direct backend access, Velocity modern forwarding for HMAC-verified proxy authentication — is not optional. It is the difference between a network that runs for years and one that gets wiped in its first week because a player found an open port.

Start small. Run the proxy and two backends on a single VPS in Mumbai. Add servers as your player base grows. Monitor your backend server tick rates (TPS), not the proxy — the proxy almost never bottlenecks first. And read the Velocity documentation at docs.papermc.io/velocity before going live. The PaperMC team maintains it well, and the security section in particular is worth reading in full.