docker Vintage Story Dedicated Server Docker Image

[Drahkar]

2 hours ago, Shijikori said:

Hey! Just letting you know I updated Vintage RCON to fix an issue with packet handling. Please make sure that your web console is compatible with the classic handling that was reimplemented in the new version!

I overlooked this when I checked the changes submitted by Taehan.

Every command packet should now receive only one packet of response. Please ensure that your console sends a SERVERDATA_RESPONSE_VALUE (packet type 0) after receiving the first response to a command. The server should respond with an empty serverdata response packet if there are no more chunks left to the response.

Feel free to communicate with me through Discord (@shijikori) if you need technical details

Refer to Valve's documentation to validate your rcon web console's client behaviour : https://developer.valvesoftware.com/wiki/Source_RCON_Protocol

@Shijikori Thanks for the heads up! I'll update the version and test. I actually suspect that may have been the cause of a id count error I was running into that ultimately had me change to an async call through the python rcon library. I'll let you know!

Edited March 5 by Drahkar

[Shijikori]

@Drahkar that's not impossible. The rework's behaviour was to spam the client with all the chunks of the response at once. I identified that problem while testing the mod on 1.22 pre-release. Assuming the python library sent the type 0 packet with a different id than the command which would then cause that id error because it would simply happen to receive the spammed packet after requesting another chunk (which would have the previous id instead of the id selected by the client for the request).

RCON clients are not expecting to receive more than a single packet per packet they send. That behaviour causes issues with clients who behave based on common specification. I was testing using ARRCON, with the small changes in version 2.0.1, ARRCON no longer had the issue where sometimes it would seemingly get no response from the server despite the command actually being passed through.

[Shijikori]

You should include in your security best practices a mention about RCON being unencrypted. That is by the specification, I recommend, myself, to never expose the RCON connectivity to untrusted networks. Your web console should be preferred if possible (and with certificates, especially over the internet). The RCON password could feasibly be snooped on an untrusted network or the internet, making a server vulnerable to griefing and anything else possible with console administrator access of a Vintage Story server software.

The RCON access should always be used with necessary precautions, be it restricting access to only the local host (requiring a more secure connection first, such as SSH, to then interact with the server via an RCON client) or using a VPN setup such as wireguard or IPsec to ensure connectivity between RCON client and the server is encrypted.

[Drahkar]

@Shijikori That is a solid recommendation. The standard configuration for the server has RCON only accessible through the WebUI, but calling it out is definitely a valid point.

I should also look into updating the process for handling the WebUI to also support using Let's Encrypt, so it will just natively support SSL, and then give them a way to deploy it with their own certs, if that is what is preferred. I've opened Github Issue #65 for implementing a solution that will allow for simple automated support, if they are using anything more than localhost access.

Edited March 6 by Drahkar
Expanded on solution.

[Shijikori]

@Drahkar Another minor update, though I'll be done for a while following that one. Version 2.0.2 of Vintage RCon improves logging and leaves more verbose traces for administrators. This can be very useful to know what the rcon connection was used for in the logs. The full command is now part of the logs (including arguments) as well as the address of the client which sent it.

Nothing changed in terms of logic and processing, so it shouldn't cause any issues if version 2.0.1 didn't give you any problems.

[Drahkar]

On 3/7/2026 at 12:52 PM, Shijikori said:

@Drahkar Another minor update, though I'll be done for a while following that one. Version 2.0.2 of Vintage RCon improves logging and leaves more verbose traces for administrators. This can be very useful to know what the rcon connection was used for in the logs. The full command is now part of the logs (including arguments) as well as the address of the client which sent it.

Nothing changed in terms of logic and processing, so it shouldn't cause any issues if version 2.0.1 didn't give you any problems.

@Shijikori Perfect. I'll make sure future builds leverage 2.0.2. I've already confirmed everything in place works with the new version, so it looks good. 

For anyone waiting on 1.22.0-rc.*, I'm sourcing your opinion.

Currently, I'm seeing a pretty consistent failure when you have more than one Mod loaded on the dedicated server. The client gets a bad request error when trying to communicate with ModDB. I've been holding off making the build, due to that error. 

Would you all like me to build it anyway?
NOTE: ALWAYS backup your saves before doing any upgrade. I've seen a few posts of people being burned because of that.