How to Fix an Omnifactory Server That Keeps Crashing
Omnifactory is the original GregTech Community Edition automation pack on Forge 1.12.2 — the one that established the 'GregTech-lite' formula later expanded by packs like Nomifactory CEu. Because it layers standard Forge mods into a GregTech-style progression without going full GT New Horizons, most of its server-side crashes trace back to a small set of well-known causes rather than anything exotic. This guide walks through them in the order you should actually check them.
See the Omnifactory pack page for the full RAM and setup breakdown before you chase anything else.
1. Confirm you're on Java 8
Omnifactory runs on Forge for Minecraft 1.12.2, and Forge 1.12.2 is built against Java 8. Running it on Java 9 or newer is one of the most-reported causes of a server that fails to boot at all, or crashes within the first few seconds before the world even generates. This is the standard first check on any instant, pre-world crash — before looking at mods, configs, or anything else.
- Check the Java binary the server launch script actually points to, not just what's installed system-wide
- A crash with no meaningful world-load progress in the log almost always points here first
2. Multiblock tick overhead as the base scales up
Once automation scales past the early game, GregTech-style multiblock machines — processing arrays, large power setups, bigger pipelines — add real per-tick cost. This is a well-documented pattern across every GregTech-inspired pack, and Omnifactory, as the pack that established this formula, is no exception.
The usual symptom isn't a clean crash. It's TPS slowly degrading as a base grows, with lag spikes that get worse under concurrent player load, eventually tipping into a tick timeout if nothing is done. If your crashes correlate with 'someone just finished a big automation setup,' this is the likely category, even before you know which specific machine is the heaviest.
3. Long-running worlds accumulate tick cost
Omnifactory is a foundational, older pack in its lineage, and worlds that have been running for a long time tend to accumulate processing-chain complexity — more active machines, more items in transit, more chunks loaded by automation — that raises tick cost in ways a fresh world simply doesn't show. If a server was fine for weeks and is now degrading, it's often this cumulative effect rather than a single new change, and it's worth comparing current TPS against what the same base looked like earlier.
4. Config or mod-list corruption after an update
If the pack version, a mod, or a config file was changed outside of a clean pack reinstall, mismatched configs are a common source of crashes that show up as a specific mod failing during world load rather than at the Forge handshake stage. Before assuming it's a deeper engine issue, compare the current mod and config set against a clean copy of the same pack version, and roll back any manual edits that happened around the time the crashes started.
5. RAM under the pack's realistic floor
6 GB is the real floor for an Omnifactory server, which can be higher than a naive estimate based on a generic 1.12.2 Forge pack. Under-provisioning rarely looks like a clean, instant crash — it shows up as cascading lag and GC pauses that get worse as more machines come online, eventually ending in a tick timeout once the server can't keep up. If crashes cluster around busier play sessions or bigger automation setups rather than happening at a fixed moment, check available RAM before anything else.
FAQ
My Omnifactory server crashes instantly on startup — what's the first thing to check?+
Confirm the server is actually running on Java 8. Forge 1.12.2 (which Omnifactory is built on) does not reliably run on Java 9+, and an instant crash at startup — before the world even loads — is almost always a Java version mismatch rather than a mod problem. Check the server's Java path and version before touching configs or mods.
Why does my server lag badly or freeze once a base gets bigger, even without crashing?+
This is the classic GregTech-lineage pattern: multiblock machines (processing arrays, large power setups) add real tick overhead as a base scales up. It's well documented across every GregTech-inspired pack, Omnifactory included. The symptom is usually gradual TPS decay and growing lag spikes under load, not a sudden crash — which points at machine density rather than a single broken mod.
How much RAM does an Omnifactory server actually need?+
6 GB is the real working floor for Omnifactory, even though a generic Forge 1.12.2 pack guess might suggest less. Below that floor, expect cascading GC pauses and rising tick time well before an outright crash — the server doesn't fail cleanly, it just gets slower until something times out.
Host Omnifactory on hardware sized for its real floor
Omnifactory needs a real 6 GB floor to stay stable as automation scales up, so provision for that from day one and take a backup before any risky config or version change.
View Minecraft Hosting →