How to Run a Plugin Pack on a 1 GB RAM Server: The Lightweight Stack Guide

Setting Expectations: The Real Limits of 1 GB

Java itself consumes 200-300 MB. The Paper core takes another 300-400 MB. That leaves a window of just 300-500 MB, and into it must fit:

• Loaded chunks
• Entities (mobs, items, armor stands)
• Player inventories
• Plugin caches
• World render sections
• Network buffers

Everything has to live inside that restricted space. That is why every optimisation here is built around saving memory, not speed.

Step 1: The Right Server Core

Choosing Spigot or Bukkit on 1 GB of RAM is suicide. Use Paper. With async chunk loading, entity optimisations and lazy chunk generation, Paper does on 1 GB what Spigot cannot.

Purpur is a good alternative too — it is a fork of Paper and includes extra optimisation flags. But Paper is the safer choice because of the breadth of its ecosystem.

Do not try Folia on 1 GB. Folia is multi-threaded, but the context switching overhead between threads does more harm than good on small servers.

Step 2: The Right Minecraft Version

Every new Minecraft version wants more RAM. 1.8 is the lightest, but modern plugins will not run on it. The sweet spot is 1.18 - 1.19. 1.20+ has nicer features but consumes 200-300 MB more RAM.

Step 3: Multi-Client Support with ViaVersion

To run an older version on the server side while still letting modern clients connect, the ViaVersion family of plugins is used:

• ViaVersion: lets newer clients join an older server
• ViaBackwards: lets older clients join a newer server
• ViaRewind: support for 1.8 and below (rarely needed)

If you install ViaVersion + ViaBackwards on a 1.18 server, every player from 1.16 through 1.21 can connect. The extra RAM cost is 20-40 MB.

Step 4: The Lightweight Plugin Stack

The minimum set of plugins needed for a Survival pack that runs on 1 GB:

Mandatory Plugins (10 of them)

• LuckPerms: permissions — 15 MB RAM
• EssentialsX: core commands — 25 MB
• EssentialsXChat: chat format — 8 MB
• Vault: API abstraction — 3 MB
• ViaVersion: multi-client — 20 MB
• CoreProtect: logging/rollback — 15 MB
• Matrix (lite config): anti-cheat — 30 MB
• PlaceholderAPI: dynamic variables — 5 MB
• TAB (basic): tab list — 12 MB
• ProtectionStones: claim system — 10 MB

That is roughly 150 MB of RAM in total. Together with the server core, 600-700 MB. You still have about 300 MB of headroom.

Heavy Plugins to Avoid

• Dynmap / BlueMap: 150-300 MB RAM on their own
• WorldEdit + WorldGuard, full package: 100+ MB
• Citizens: 5-10 MB per NPC
• Holograms + DecentHolograms: 40 MB
• AuctionHouse (complex): 50+ MB
• FactionsUUID / Towny: 80+ MB
• Shopkeepers + ShopGUIPlus: 60+ MB
• Skript: 50-200 MB depending on the number of scripts
• MMOItems / MythicMobs: 100+ MB

Step 5: JVM Settings with Aikar's Flags

On heaps as small as 1 GB, the default GC settings perform very badly. Using Aikar's flags is mandatory.

#!/bin/bash
# start.sh — optimised for 1 GB RAM

java -Xms1G -Xmx1G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -Dusing.aikars.flags=https://mcflags.emc.gs \
  -Daikars.new.flags=true \
  -jar paper-1.18.2-XXX.jar nogui

Step 6: paper-global.yml Tuning

The settings in Paper's config/paper-global.yml file that affect memory the most:

chunk-loading:
  autoconfig-send-distance: true
  enable-frustum-priority: true
  max-concurrent-sends: 1
  min-load-radius: 2
  player-max-concurrent-loads: 10.0
  target-player-chunk-send-rate: 50.0

chunk-loading-advanced:
  auto-config-send-distance: true

world-settings:
  default:
    chunks:
      auto-save-interval: 6000   # 6000 ticks = 5 min
      delay-chunk-unloads-by: 10s
      max-auto-save-chunks-per-tick: 24
    collisions:
      max-entity-collisions: 4   # default 8
    entities:
      spawning:
        per-player-mob-spawns: true  # mob spawns limited per player
    misc:
      prevent-moving-into-unloaded-chunks: true

Step 7: spigot.yml Entity Limits

The old spigot.yml settings that are still critical:

world-settings:
  default:
    entity-tracking-range:
      players: 48      # default 48
      animals: 32      # default 48 → lowered to 32
      monsters: 32     # default 48 → lowered to 32
      misc: 16         # default 32 → down to 16
      other: 32
    entity-activation-range:
      animals: 16      # default 32
      monsters: 16     # default 32
      raiders: 48
      misc: 4          # default 16
    mob-spawn-range: 4 # default 8
    view-distance: 6   # default 10
    simulation-distance: 4 # default 10

Step 8: bukkit.yml Mob and Spawn Settings

spawn-limits:
  monsters: 30    # default 70
  animals: 6      # default 10
  water-animals: 2 # default 5
  ambient: 1      # default 15

chunk-gc:
  period-in-ticks: 400  # once every 20 seconds

ticks-per:
  animal-spawns: 400
  monster-spawns: 10
  autosave: 6000  # 5 min

The monsters: 30 setting cuts the mob count on your server by 60%. If players complain that the villages are empty, you can raise it to 40; above 50 it gets heavy again.

Step 9: server.properties Optimisation

# Critical settings for low RAM
view-distance=6
simulation-distance=4
max-players=15
network-compression-threshold=256
entity-broadcast-range-percentage=100
enable-status=true
use-native-transport=true
enable-command-block=false
spawn-protection=0
sync-chunk-writes=false

Step 10: World Management

Do not open more than one world on 1 GB of RAM. Delete or disable the Nether and the End. Every extra world consumes 50-100 MB of RAM.

# bukkit.yml
worlds:
  world_nether:
    generator: null
  world_the_end:
    generator: null

Limit the size of the world as well:

# Set the border — 2000x2000 blocks
/worldborder set 4000

Step 11: Plugin Configuration

Leaving every plugin on its default settings is the root of most problems on 1 GB. The settings you specifically need to turn off in each plugin's config:

EssentialsX

remove-god-on-disconnect: true
auto-afk: 300  # AFK after 5 min
social-spy: false
warn-on-build-disallow: false
sign-storage-limit: 50
starting-balance: 0
minimum-pay-amount: 0.01

# Turning off unnecessary features
match-colors: false
teleport-delay: 0
death-messages: true

CoreProtect

disable-world-edit: true       # turn off WorldEdit logging
check-updates: false            # turn off the update check
use-mysql: false                # SQLite is lighter on a small server
rollback-items: true
default-radius: 10              # the default of 100 is far too wide

Matrix (Anti-cheat)

general:
  debug: false
  async-check-optimization: true

checks:
  killaura:
    enabled: true
    # Only enable the basic checks, turn the advanced ones off
    max-attacks-per-second: 20
    angle-check: true
    post-check: false    # heavy check, turn it off

Step 12: Swap File (The Difficult Fix)

A 1 GB RAM VPS with no Linux swap space cannot cope with memory pressure. Adding swap:

# Add 2 GB of swap
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Add it to fstab to make it permanent
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Swappiness setting (10 is ideal for Minecraft)
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Step 13: Monitoring and Improving

Once you have applied the settings, measure whether the server really did improve:

# In the server console:
/tps          # TPS value — 20 is ideal, 18+ is acceptable
/mem          # Memory usage — under 80% is ideal
/spark profiler --timeout 60  # a one-minute profile

The Spark report is the single most important diagnostic tool. The easiest way to analyse the profile:

What Changes When You Move Up to 2 GB?

Going from 1 GB to 2 GB is the biggest performance jump there is. What you can additionally do on 2 GB:

• The plugin count can go from 20 up to 35
• The Nether and the End can be opened
• View-distance can go up to 8
• The player limit can go up to 25
• A lite build of Dynmap can be tried
• MySQL becomes usable (instead of SQLite)
• A small Citizens NPC setup
• A basic economy + shop plugin

When Should You Upgrade to 4 GB?

If you see any of these signals, it is time to move up to 4 GB:

• An average of 15+ players online
• Plans to move to a mini-game, SkyBlock or Faction mode
• TPS constantly below 17
• The server locking up every ten minutes
• OutOfMemoryError in the log
• Players complaining that the lag is terrible
• You want to add a UI plugin such as Dynmap

Visual Plugin Alternatives (on Low RAM)

You want some visual flair in your pack, but your RAM is tight. Lightweight alternatives:

The Server Capacity Formula

To work out how many concurrent players 1 GB of RAM can carry:

Usable RAM = Total RAM - Java overhead (200 MB) - Paper (300 MB) - Plugins (~150 MB)
                  = 1024 MB - 200 - 300 - 150
                  = 374 MB

Average RAM usage per player:
- Inventory and data: ~10 MB
- Loaded chunks: ~15-25 MB (depends on view-distance)
- Entities: ~5 MB
- Total: ~30-40 MB per player

Maximum player count = 374 / 35 = ~10 players

So the practical ceiling on 1 GB is 10 players. You can try 15, but it stays extremely tight. Move up to 2 GB and that number rises to 25-30.

What to Watch for When Choosing a VPS Provider

What to look at beyond price when shopping for a cheap 1 GB RAM VPS:

• Is the disk NVMe, SSD or HDD? It must be NVMe. On an HDD, Minecraft chunk loading is dreadful.
• CPU frequency: below 2.5 GHz is not enough for Minecraft. 3 GHz+ is ideal.
• Network: a 1 Gbps link is essential; on shared 100 Mbps you get ping problems
• Location: Istanbul/Frankfurt for Turkish players. An American server means 120+ ms of ping.
• DDoS protection: cheap VPS plans usually have none; a Minecraft server attracts attacks
• Bandwidth: unlimited, or at least 1 TB/month
• IPv4: IPv6-only VPS boxes cause problems for Minecraft

Frequently Asked Questions

Why does my TPS drop when players join?

Every player increases the number of loaded chunks. With view-distance 6 each player loads about 169 chunks; 10 players = 1,690 chunks. 1 GB of RAM cannot hold that many chunks comfortably, the GC starts running constantly and TPS drops. The fix: you can lower view-distance as far as 4 (81 chunks per player).

Does using Purpur instead of Paper save RAM?

Marginally. Purpur's extra optimisation flags can use RAM 5-10% better, but they do not make a critical difference. The real gains come from view-distance, entity limits and plugin choice. Using Paper is the safer bet for ecosystem compatibility.

Does adding swap space really help?

It softens memory pressure but does serious damage to performance. Once swap starts being used, Minecraft chunk loading takes seconds; players look literally frozen. Keep swap as a last resort — the real fix is more RAM. Track your swap usage with free -h; it should be zero.

Would ZGC be better than G1GC?

ZGC (Java 15+) focuses on low pause times but requires a heap of at least 2 GB. It will not work on 1 GB; G1GC is the best choice there. For servers with 4 GB+ of RAM, ZGC or Shenandoah GC are worth evaluating as alternatives.

What if I set plugins to disabled instead of removing them?

Writing enabled: false in plugin.yml stops the plugin from loading, but the jar is still parsed into memory. For a real saving, move the jar somewhere else such as plugins/disabled/; Paper never scans that.

Timing the Move from 1 GB to 2 GB

Staying on 1 GB is not always worth it. Which signals should make you consider moving to 2 GB?

• An average of 7-10 players online has become permanent
• The plugin count has crept from 15 towards 20
• RAM sits above 70% even when the server is empty
• Can't keep up messages have become frequent in the log
• Chunk loading time has passed 5 seconds
• The Spark profile shows 30%+ of time spent in GC

Moving to 2 GB usually takes the price from 100 TL to 200 TL. The comfort you get for that is worth it: you can raise the plugin count, open the Nether/End, and push view-distance to 8.

Free Improvements: Zero Cost

Every optimisation you can make without adding RAM:

• Add Aikar's flags — +15% performance
• Drop view-distance from 10 to 6 — +35% RAM saved
• Lower entity-activation-range — +10% CPU saved
• Remove unnecessary plugins — 5-15% improvement
• Switch to Paper (from Spigot) — +20% performance
• Pre-generate the world with Chunky — chunk generation spikes disappear

MySQL vs SQLite: Which to Pick on Low RAM?

The database choice in your plugin pack has a direct effect on RAM usage.

SQLite advantages (for 1 GB)

• Almost zero RAM usage — each plugin opens its own .db file
• No installation — no service is running
• Single file — easy to back up
• No connection pool — minimal overhead

SQLite disadvantages

• Concurrent writes are slow — lag when 10+ players use the shop at once
• On large databases the VACUUM operation causes a lock-up
• No cross-plugin queries — every plugin lives in its own file
• Cannot be shared across a BungeeCord network

MySQL/MariaDB (MariaDB is the lighter one)

MariaDB, as a separate service, consumes 150-250 MB of RAM. That is 15-20% of your 1 GB total. But its advantages in connection pooling, concurrent writes and performance are considerable. On 2 GB of RAM you can use MariaDB; on 1 GB, stay loyal to SQLite.

Chunk Pre-Generation: Building the World in Advance

Chunk generation is a very heavy operation. Every time a new chunk is generated there is a 50-200 ms CPU spike. Generating the world in advance is critical to the flow of the game.

# With the Chunky plugin
/chunky radius 2000
/chunky start
# A 2000x2000 block area is generated in the background

# Progress
/chunky progress

# Until it finishes (this can take hours)
/chunky pause    # pause
/chunky continue # resume

Chunky splits chunk generation across ticks, so it does not affect TPS while people are actually playing. Even so, it is best to run it at night or when the player count is low.

Summary: Surviving on 1 GB

To run a professional plugin pack on a 1 GB RAM server: the Paper core + version 1.18 + Aikar's flags + view-distance 6 + 15 lightweight plugins + paper.yml tuning + spigot.yml entity limits + bukkit.yml spawn limits + 2 GB of swap. With that formula a 5-10 player Survival server runs stably at 18-19 TPS. Replace visual plugins with their lightweight alternatives, and pick your VPS provider on the NVMe + 3 GHz+ CPU criteria. Use SQLite, and pre-generate the world with Chunky. But remember: 1 GB is the upper limit — in the long run, as your server grows, upgrading to at least 4 GB will be unavoidable. Until then, this guide is where you start.

The most important discipline on a 1 GB RAM server: everything unnecessary must be turned off. The modern Minecraft server ecosystem encourages a more equals better mindset; you get used to servers with 100 plugins. On 1 GB, though, you have to stay few but efficient. Question whether each plugin is genuinely necessary.

Resource Monitoring Commands

On a 1 GB server every megabyte matters. Learn the performance monitoring commands:

# RAM usage
free -h

# Top processes
top -o %MEM
htop  # visual alternative

# Java process memory
jps
jcmd <pid> GC.heap_info

# Disk usage
df -h
du -sh plugins/ world/ logs/

# CPU load average
uptime

# Inside the server
/tps
/mem
/spark health

Checking these commands daily is the best way to keep a finger on your server's pulse. The moment you see an abnormal value, investigate immediately; find the root cause.

Optimising a small server is as hard as launching a big one, but it is a different skill. The discipline of working with low resources gives you priceless experience on the larger servers that come later. Someone who masters constrained environments will certainly master well-resourced ones.

Running a 1 GB RAM server over the long term teaches you a great many valuable lessons: the cost of every plugin, the importance of structure, the lightweight alternatives. That experience lets you make more informed decisions when you move to bigger servers. Starting cheap has long-term value. By the time you upgrade to 4 GB, what you have learned along the way cannot be measured in money.