Cost-Effective Valheim Game Server on Azure with Discord Bot
Intro
This blog post will guide you through building a cost-effective Valheim game server on Azure, complete with a Discord bot that allows players to start and stop the server using slash commands. The setup leverages Azure’s serverless capabilities and spot instances to minimize costs while providing flexibility and scalability.
Architecture
The system’s interaction flow starts with Discord slash commands, which are handled by an HTTP-triggered Azure Function (interactions). Discord requires a response within 3 seconds, so the API’s only responsibility is to enqueue the command in an events queue and quickly respond.
Another queue-triggered Azure Function (reactions) picks up the command, performs the requested task (e.g., starting the server), and reports back to Discord.
Game Events
To enhance the experience, the solution monitors Valheim game server logs and reports events such as:
- Server availability for connections
- Player connections
- Player disconnections
This is achieved with a script configured with cloud-init.yml that runs on the VM. The script listens to the container logs, extracts relevant log lines, and enqueues them in the events queue.
Persisting State
To maintain the server state, I chose Azure Table Storage for its simplicity and cost-efficiency. The following attributes are persisted:
- ip (server IP address)
- online_players (number of players currently online)
- status (e.g., running, stopped)
Azure Function OS and Language Choice
One of the biggest challenges was ensuring the bot responded within Discord’s 3-second timeout, even during cold starts.
- Initial Setup: I started with a Python bot on a Linux Azure Function. However, cold starts frequently caused timeouts.
- Switch to Go: I migrated to Go, known for its faster performance. Surprisingly, deploying the Go bot on a Windows Function App yielded significantly better cold start times compared to Linux.
Possible Improvements
While the setup works well, there’s room for improvement:
- Spot Instance Risks: Spot instances can be preempted, risking progress loss if the game server isn’t stopped gracefully. A solution involves monitoring Azure’s scheduled events endpoint. Upon detecting a preemption event, the VM can:
- Stop the Valheim server (docker stop valheim-server) to send a SIGTERM, triggering a world save.
- Restart the server in a different zone or instance size.
- Additional Features:
- Automating backups of the game world.
- Adding more granular state persistence, such as player-specific data.
Conclusion
This blog post has demonstrated how to build a cost-effective Valheim game server on Azure, complete with a Discord bot that allows players to start and stop the server using slash commands. By leveraging Azure’s serverless capabilities and spot instances, the setup minimizes costs while providing flexibility and scalability.
FAQs
Q: What is the primary goal of this setup?
A: The primary goal is to create a server as cost-effectively as possible by utilizing Azure Virtual Machine Scale Sets with spot instances for compute, Azure File Share for persistent game server data, and Azure Functions for event-driven automation through Discord slash commands.
Q: What is the choice behind using Azure Functions?
A: Azure Functions were chosen for their cost-effectiveness, offering 1 million free executions per month. However, this choice introduces some complexities, which are discussed in the article.
Q: How does the solution persist server state?
A: The solution persists server state using Azure Table Storage, which is simple and cost-efficient. The following attributes are persisted: ip, online_players, and status.
