Is It Legal to Host a Factorio Server? Wube's EULA, the Docker Redistribution Trap, and Staying Compliant
If you are about to stand up a Factorio dedicated server - on your own hardware, a rented VPS, or a managed host - you have probably wondered whether you are allowed to. The short answer is yes: running a Factorio server is explicitly permitted, including for a commercial hosting business. The longer answer is that there is one line you cannot cross, and a surprising number of DIY setups cross it by accident. This guide walks through what Wube Software's Terms of Service actually say, where the common mistake hides, and how to stay on the right side of it.
This is not legal advice. It is a plain reading of the public terms Wube publishes for Factorio plus the well-documented community consensus around them. For anything load-bearing, read the source yourself at factorio.com/terms-of-service and, if you are building a commercial product on top of it, talk to a lawyer.
The question: do I need to own the game, and am I allowed to host it?
Two separate questions usually get tangled together here.
- Do I need a paid copy of Factorio to run a server? No. The headless server is a free download. You do not need to own a license to obtain or run the headless build itself - it is published for anyone with a factorio.com account to download.
- Am I allowed to run a server at all, including charging money for it? Yes. Wube's terms explicitly allow you to use the free headless server to run and operate a commercial hosting service.
So the gate is not "do you own the game" and it is not "are you allowed to host." Both of those are fine. The gate is how the server software is distributed. That is the part people get wrong.
What Wube's Terms of Service allow
Two clauses matter most for anyone hosting. First, on running the server - including as a business. Wube's terms state:
"You may use the free Factorio headless server to run and operate a commercial service providing servers to players."
That is unusually generous for a paid indie game and it is worth appreciating: Wube is not merely tolerating server hosts, it is explicitly sanctioning them, including ones that charge customers. The terms do attach a caveat - Wube reserves the right to request that a service cease operating if a problem with the provider arises - but the baseline permission to run a commercial Factorio hosting service is right there in writing.
Second, on ownership. Factorio is licensed, not sold. The terms make this explicit:
"Factorio is licensed, not sold. No title or ownership in Factorio is being transferred or assigned."
Wube Software Ltd. retains all right, title, and interest to Factorio, including the copyrights, trademarks, source code, and art assets. You are granted a license to use the software; you do not own the bits and you cannot treat them as yours to hand around. That framing is the key to understanding the one thing you are not allowed to do.
What Wube's Terms of Service forbid: redistributing the binary
The prohibition is short and broad:
"You are not allowed to copy, transfer or distribute the game, its hacked or otherwise altered versions, any of its parts or any of the paid content."
Read that carefully. "Any of its parts" includes the headless server binary. The headless build being a free download does not make it a redistributable one. Free-to-download and free-to-republish are two different permissions, and Wube grants only the first. You may fetch the headless server from the official channel as many times as you like. You may run it. You may build a business around running it. What you may not do is take that binary and re-publish it - copy it into a package, bake it into an image, mirror it on your own server, or ship it bundled inside something else you hand to other people.
This is the same model most commercial software uses: the vendor distributes, you consume. The wrinkle with Factorio is that the headless server is so trivially easy to grab and tar up that re-publishing it feels harmless. It is not harmless under the terms, and the most common place this happens is Docker.
The Docker redistribution trap
Containerizing a Factorio server is a popular DIY pattern, and it is where the redistribution line gets crossed most often - usually without anyone intending to break a rule.
There are two ways to put Factorio in a container image, and they are not equivalent under the terms:
| Pattern | What happens | Status |
|---|---|---|
| Bake the binary in at build time | The Dockerfile downloads the headless server during the image build and commits it into a layer. The published image now contains the Factorio server. | Redistribution. Publishing that image hands Wube's binary to whoever pulls it. |
| Download at runtime from the official channel | The image ships only your scripts and config. On first start, the container fetches the headless server from factorio.com itself. The published image contains none of Wube's code. | Compliant. Each user obtains the binary directly from Wube. |
The distinction is exactly the one the Factorio community has settled on. As the long-running discussion on the topic puts it: as long as the Docker image does not contain Factorio or its server, but instead downloads them through the official channels when you first start it, then it complies with the Factorio terms. A public image with the server binary baked into a layer is redistributing "a part" of Factorio to everyone who runs docker pull; an image that fetches at runtime is not.
This is not theoretical. Maintainers of community container tooling around Factorio - including the clustered-server ecosystem built on top of the headless build, and the widely used factoriotools/factorio-docker image - have deliberately moved to the download-at-runtime model precisely so the published artifact does not bundle the server. The factoriotools image is explicit that it ships "only the server" infrastructure and points users to obtain the full game from official channels; the binary is pulled, not packaged. If you maintain or fork any of these projects, check whether your build step commits the headless tarball into the image. If it does, your published image is redistributing the server, and switching to a runtime download fixes it.
Quick self-check for any image you publish: run docker history on it, or unpack the layers, and look for the Factorio binary or tarball. If bin/x64/factorio or factorio_headless*.tar.xz is sitting inside a committed layer, you are shipping Wube's code. Move the download into the container entrypoint so it happens on first run instead.
What this means when you choose a host
If you rent a managed Factorio server rather than running your own, the redistribution question lands on the host, not on you. A host operating compliantly does exactly what the terms allow: it obtains the headless server from the official channel, installs it onto the machine that runs your world, keeps it updated, and never republishes the binary as a public artifact. You, the customer, are paying for the service of having a server run for you - which is squarely the "commercial service providing servers to players" that Wube sanctions. You are not redistributing anything, because nothing is being handed to you; the software runs on the host's infrastructure and you connect to it like any player.
That is the practical upside of a legitimately operated managed host. The "do I own a copy, am I allowed to host, did I obtain the binary the right way" trio is all handled correctly, and the one trap that catches DIY container builds simply does not apply to you. You still need your own Factorio account for the things accounts are for - generating the server token for the public browser and downloading mods from the portal - but the server binary acquisition and the redistribution exposure are the host's responsibility, done the way the terms intend.
Self-host the right way: a short checklist
If you are running your own server, staying compliant is genuinely easy. The whole list is short:
- Download the headless server from the official channel - factorio.com/download/headless - with your factorio.com account. Do not source the binary from a third-party mirror or a baked container layer.
- Run it as much as you like. Running the server, including for paying customers, is explicitly allowed.
- Do not republish the binary. No public Docker images with the server baked in, no mirrors, no torrents, no "here is my ready-to-go bundle" archives that include Wube's code.
- If you containerize, fetch at runtime. Keep Wube's code out of any image you publish; download it from the official channel when the container first starts.
- Keep your own account. The server token and mod-portal access are tied to your factorio.com account, which is separate from the redistribution question entirely.
- If in doubt, read the source. The terms are short and plainly written: factorio.com/terms-of-service.
None of this is onerous. The headless build is free, the right to host is granted, and the only real discipline required is "obtain from Wube, never re-publish." Get that one habit right and you are compliant.
Related reading
- How to Host a Factorio Headless Server (Linux + SteamCMD) - the actual install and launch steps.
- Factorio Linux Headless Server: Complete Systemd Setup Guide - running the headless build as a managed service.
- Official: Factorio Terms of Service
- Official: Factorio headless package download
Host a Factorio server without the redistribution headache
Supercraft runs Factorio dedicated servers the way the terms intend: the headless build is pulled from the official channel, installed onto the node that runs your world, and kept updated for you. Nothing is republished, you are not redistributing anything, and you connect like any other player. You bring your factorio.com account for the token and mods; we handle the binary acquisition and updates legitimately.