ValleyServer, running a Stardew Valley farm without a player

Two architectures, one project, and only one of them is for keeping

ValleyServer is a dedicated server for Stardew Valley, and the description is direct about what it does: it lets a Stardew Valley farm keep running when no real person is operating it, and it provides a multiplayer server you can connect to directly.

The project contains two main lines that do not depend on each other, and the distinction is the most important thing in the repository.

The 2.x line is a mod and Docker approach. It runs automation mods on the real game client, including automatic sleeping, skipping story sequences and closing pop-up windows, deployed with Docker in one step. This line is in maintenance mode.

The 3.x line takes a different approach entirely. Instead of the game, it loads decompiled assemblies, builds a headless native server with no GUI, and drives the protocol through reflection and mocks. This line is described as experimental.

The comparison table in the documentation lines the two up directly. The 2.x principle is the real game with `SMAPI` and an automation mod, its status is maintenance mode with only fix-level maintenance, and it is aimed at servers already in operation. The 3.x principle is loading decompiled assemblies and driving them with reflection and mocks, its status is experimental and not recommended for production, and it is aimed at people who want to try it, study the multiplayer protocol, or take part in development. The stated advantage of 3.x is that it keeps the benefits of 2.x while being more convenient to use and lighter on resources.

The selection guidance is equally blunt. For long-term stable operation, 2.x still works but is frozen, and the documentation points at JunimoServer as a project with a similar niche. For trying 3.x or contributing to it, start with the 3.x documentation. A version guide holds the full comparison and decision path.

The audience is therefore two different people: an operator of an existing containerised server who wants it to keep running unattended, and a developer interested in the multiplayer protocol.

The 2.x line runs the actual game inside Docker

The 2.x architecture keeps the real game client in the loop, which is what makes it behave like the game your players know.

The starting point is SMAPI, the Stardew Modding API, which provides the game injection and extension mechanism. On top of that sit the automation mods, and the `Mods/` directory in the repository contains the mod set with a README per mod describing its function and configuration. The documentation lists SMAPI as the project it thanks for providing the injection and extension mechanism.

The deployment is a shell script in the `oneclick-script/` directory.

cd oneclick-script
bash ./run.sh

That is the whole start procedure, and the deployment manual in `docs/v2/cookbook.md` covers the ports, the directory mounts and how to read the orchestration files.

Once it is up, you open `http://<server IP>:5800` in a browser to reach the web interface, then open the VNC page and enter the connection password, which defaults to `041041`. The VNC route is there because the game runs with a window, and the web interface is the layer in front of it.

One thing to plan for is that the `Mods/` directory is empty on first run. The documentation says you need to put mods such as `ALOS` in yourself, which means the container image and the mod set are separate concerns, and the mod set is what makes the farm unattended. The v2 documentation has a MOD list section for that.

The important caveat is stated in a callout above the quick start. The 2.x line is in maintenance mode and will not accept merge requests for feature enhancements or container management approaches, and only fixes for crashes and compatibility problems are taken. Existing deployments continue to work, and the images and the deployment manual are kept.

So this line is the stable, understood, community-shaped option, and the project is explicit that it is not where new work happens.

The 3.x line loads decompiled assemblies and mocks the protocol

The 3.x line replaces the game rather than automating it, and that is where the interesting engineering and the sharpest trade-off both sit.

The start procedure is a download rather than a script. You take `ValleyServer-<platform>-x64.zip` from the Releases page, unpack it and run the executable directly, and it ships with its own .NET runtime so there is nothing to install first. On first start it generates a `config.json`, it listens on `24642/udp` by default, and the console accepts `help` to list the available commands.

A default UDP port and a console command set are what you would expect from a server implementation, and the fact that the runtime is bundled is a deliberate choice for a binary distribution, where asking a player to install a matching .NET runtime is a support burden.

The 3.x documentation covers the build, the configuration options and the known limitations, and the repository has a `src/` directory and a `Lixeer.ValleyServer.slnx` solution file at the root, so the server is a .NET project.

The trade-off is the one the project states plainly. This is a mock protocol end driven by reflection over decompiled assemblies, it is experimental, and it is not recommended for production. Building a protocol-compatible server from a decompiled client means two things follow. The first is that the protocol will track whatever the game version does, including anything the game does not document. The second is that it sits in a legally and contractually different place from the 2.x line, which runs the genuine game under the genuine modding API.

For a project that serves a community, that difference is not academic. The 2.x line is the configuration the project's own documentation calls the long-term stable option, and 3.x is the research track.

The community and support section is also in Chinese, with QQ groups and a QQ channel for release announcements, and the issue tracker is restricted. The documentation states that the issue area only accepts feature requests related to mods, and does not accept requests such as adapting to a particular management panel or a particular deployment method, since those are community driven and outside the scope of this repository. The project asks people with a working deployment to submit a pull request adding the repository link to the documentation.

That is a clear statement of what the maintainers want to spend their time on, and it is worth reading before you file anything.

The mod licences are not the project licence

The repository as a whole is distributed under the Apache License 2.0, and the licence file sits at the root. That is the straightforward part.

The complication is the `Mods/` directory, and the documentation is explicit that some of the mods there are secondary development works that follow their own original terms. The example given is `ALOS`, which is based on the perkmi Always-On-Server-for-Multiplayer project and uses the MIT licence plus additional terms, and the instruction for commercial use is to credit the original repository address. The third-party mods packaged in the `release` page retain the copyright of their respective authors.

So there are two licence layers. The server code is Apache-2.0. The mods that make the farm unattended carry their own terms, and shipping a 2.x deployment commercially means dealing with each mod's licence rather than just the repository's.

That is not unusual for a mod-based project, and it is the reason the `Mods/*/README.md` files exist, since the documentation navigation table lists them as documents describing each mod's function and configuration.

The acknowledgements also point at a related ecosystem. SMAPI is credited for the injection and extension mechanism, the Stardew Valley site is the official one, stardew-multiplayer-docker is credited as a Docker deployment approach for Stardew Valley multiplayer, and JunimoServer is credited as another open-source unattended server option with a similar niche. That last one is the comparison the version guide itself makes, and it is the alternative to consider if you want a maintained server rather than a frozen one.

The difference in approach between the two projects is that ValleyServer's 2.x line automates the real game, whereas a Docker-based multiplayer approach runs the game for real players. The same project therefore serves two different needs, and the project documentation does not go out of its way to blur them.

What to verify before you point a community at it

The project is honestly documented about its own state, so the checks a new operator should run are mostly about which line you are on.

For the 2.x line, the decisions are about the mod set and the deployment. The `Mods/` directory starts empty and you supply the mods, so you need to know which mods you are running and read their individual READMEs for the configuration options. You need the container to be reachable on the port the web interface expects, and you need the VNC password, which defaults to `041041` and is a password you should change before the server is exposed to anyone else. The deployment manual covers the ports, the mounts and the orchestration files, and it is the document to read before you change any of them.

For the 3.x line, the checks are about expectations. The status is experimental and not recommended for production, the port is `24642/udp` by default, and the server writes a `config.json` on first start, so you need to know what you are going to change in it. The 3.x documentation lists the known limitations, and that list is the thing to read before promising anyone a stable service.

The version guide is the document that ties the two together, and reading it first is the cheapest way to avoid installing the wrong line and then migrating.

There is also the question of what a community expects from a game server, and that is where the honest answer is that this project is one option rather than the only one. The documentation itself names JunimoServer as another open-source unattended server in a similar niche, and the 2.x line is frozen for new features. For a group that needs ongoing development rather than maintenance, a project that still accepts feature work is the better fit.

What the project does offer that is unusual is a 2.x and 3.x comparison in one place, with a decision path, which is more than most projects in this space bother to write down.

Editorial conclusion

ValleyServer suits a group that already runs a 2.x container and wants it to keep ticking with nobody at the keyboard, and it suits a developer who wants to study the multiplayer protocol. It does not suit a new deployment that wants a maintained, supported server, because the 2.x line is frozen for new features and the 3.x line is labelled experimental and not recommended for production. Verify first which line you are installing, that the mods you need are present in the `Mods/` directory, and that your players are content with the 3.x protocol not being the real game's protocol, before you point a community at it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Lixeer/ValleyServer on GitHub
4. README
5. Releases