Setting up a dedicated Don't Starve Together server in AWS

Don’t Starve Together is best experienced with friends, so you’ll want a server to host your adventures. While any player can host a game locally, a dedicated server is needed for the best experience. There’s a pretty good guide on how to set up a dedicated DST server available on the DST wiki, but there are a number of issues specific to running on an EC2 instance that the guide doesn’t cover, which is what I’ll talk about here.

Setting up your EC2 instance and SSH access

I’m using a t2.micro EC2 instance running the Ubuntu AMI offered by Amazon, although you can probably choose whichever distribution you’re most comfortable with. Some tips on setting up your EC2 instance:

a micro instance should be enough for 5-6 players and it is covered by the Amazon Free Tier, if that’s available for your account;
use persistent EBS storage - EC2s go down occasionally and the default storage is not persistent (it is lost when the virtual machine is stopped), so make sure to attach an EBS storage in order to keep everyone’s progress safe; you should also set the EBS to not be deleted automatically when the instance is terminated;
use a region that’s closest to your physical location (such as eu-west-1 in Ireland if you’re based in Europe);
when setting up the Security Group for your instance, remember to keep TCP 22 open for SSH, as well as another UDP port for the game server (default is 10999).

Once you have your instance up and you’ve connected to it via SSH, follow the steps in the guide for installing the DST server. At some point you’ll reach the following command:

screen -S "DST Server" ./dontstarve_dedicated_server_nullrenderer

Attempting that will result in the following error:

Cannot open your terminal 'dev/pts/0' - please check.

The reason behind that error is that you cannot use the screen command on a different user that the one you’ve connected as via SSH. Since you’ve logged in as ubuntu, trying to use screen as the steam user fails.

A workaround for this issue would be to allow a SSH connection as user steam, which you can do by following the advice of this post on adding new SSH users to an EC2. Since we already have a key and a user, our instructions are:

cd /home/steam
mkdir .ssh
chmod 700 .ssh
chown steam:steam .ssh
cp /home/ubuntu/.ssh/authorized_keys .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
chown steam:steam .ssh/authorized_keys

Once that’s done, log out of SSH, log back in as the steam user and run the server. You should run into an issue concerning a missing cluster token, just follow the guide on how to generate such a token and how to configure your server.

Configuring the server and setting a password

When setting up you settings.ini file, I highly recommend you set pause_when_empty to true so that the server is paused when nobody is connected.

Another issue I encountered was that the server_password field didn’t actually do anything, the server would always be configured not to use a password. That was a big issue since the server showed up in the in-game server browser and we only wanted to keep this for ourselves.

Turns out you actually need to set up a separate configuration file for each cluster in your server. By default you only have one cluster, so you’ll need to create /home/steam/.klei/DoNotStarveTogether/Cluster_1/cluster.ini and populate it with values. Here’s an example configuration:

[GAMEPLAY]
game_mode = survival
max_players = 16
pvp = false
pause_when_empty = true

[NETWORK]
tick_rate = 30
cluster_description = My awesome cluster
cluster_name = My cluster
cluster_intention = cooperative
cluster_password = myPassword

[MISC]
console_enabled = true

Connecting to the dedicated server

Once you’ve finished following the guide and the server is up and running, open up the game, access the console and run the following command:

c_connect("192.168.0.0", 10999)

Obviously you’ll need to substitute that IP with the public (not private!) IP of your EC2 instance. If you’re using a port other than 10999, you’ll also need to substitute that with your own.

If you’ve set a password, you’ll need to include it as the third parameter for the call, like so:

c_connect("192.168.0.0", 10999, "myPassword")

That should cover the AWS-specific issues I’ve encountered. Good luck!