Getting Started - Servers
Learn by doing and deploy your first Dedicated Server on Edgegap. By the end of this guide, you will have deployed a dedicated server with Edgegap at no cost.
Building with Docker Desktop is the fastest, easiest, and most reliable method to get started.
✔️ Preparation
Before you get started, make sure to create a free account with Edgegap (no credit card required).
Configure a few essentials on your development machine:
Install Edgegap Quickstart Docker Extension
Install from Docker Desktop / Extensions / Browse or using the link.
⚙️ 1. Configure Project
Whether you’re using a Windows, Mac, or a Linux machine, you will need to build your server for Linux runtime, as most cloud providers nowadays (including Edgegap) run on Linux. Don’t worry, no Linux knowledge is required.
☑️ Start by verifying your Unreal Engine version - pre-filled with value from your project files.
☑️ Input GitHub username and from ✔️ Preparation, to download dependencies from GitHub.
☑️ Disable Unreal Engine version compatibility check for dedicated servers and set IpNetDriver as the default driver or the fallback driver for replication networking:
Make sure to input your DefaultServerTarget at the end of this snippet!
net.IgnoreNetworkChecksumMismatch=1
net.CurrentHandshakeVersion=2
net.MinHandshakeVersion=2
net.VerifyNetSessionID=0
net.VerifyNetClientID=0
!NetDriverDefinitions=ClearArray
+NetDriverDefinitions=(DefName="GameNetDriver",DriverClassName="OnlineSubsystemUtils.IpNetDriver",DriverClassNameFallback="OnlineSubsystemUtils.IpNetDriver")
MaxClientRate=1000000000
MaxInternetClientRate=1000000000
InitialConnectTimeout=120.0
MaxNetTickRate=60
NetServerMaxTickRate=60
DefaultServerTarget=LyraServer☑️ Restart Unreal Engine to reload latest changes.
☑️ Create a dedicated server target script by copying your <PROJECT>Editor.Target.cs file in project root folder and renaming the copy to <PROJECT>Server.Target.cs.
☑️ Replace any references to word Editor with Server in your server target script.
☑️ Enable standard output server logs by adding overrides in your server target script:
bUseLoggingInShipping = true;
bOverrideBuildEnvironment = true;✅ You may now proceed to the next step.
🔧 2. Build Game Server
Now we'll build and cook your project, and package it in an easily reusable docker image.
Working in a team of developers means sharing your code. When things go wrong, the last thing you want to hear is “it works on my machine”. Game servers have to run reliably on any machine, since a successful games’ servers will run on thousands of server machines across the world.
To help make your server reliable, we use Docker - virtualization software to ensuring that all of your server code dependencies down to the operating system level are going to be always exactly the same, no matter how or where the server is launched.
☑️ You may configure the following options (or keep defaults):
Image name is a unique identifier of your choice, labeling your server build before shipping.
Usually, this will include the name of your game - for example “my-game-server”.
Image tag is an identifier pointing to a specific version of your image.
The term “build artifact” is sometimes used to refer to a specific version of your image.
Timestamps are a great option for tagging, e.g.
2024.01.30-16.23.00-UTC(default).
☑️ Build Project once you're satisfied with your configuration. Completing this step will add a new image with your linux game server executable in your local Docker client.
✅ You may now proceed to the next step.
🧪 3. Test Server Locally
Let’s try deploying locally (on your machine) and connecting a game client, to make sure the server image is functioning properly before we upload and deploy (which may take a bit of time).
☑️ Select the image tag you wish to run locally (remote images will be downloaded). Optionally, more docker run arguments can be supplied to customize your local test:
-p 7777:7777/udp- this is your local container port mapping,-e ARBITRIUM_PORT_GAMEPORT_INTERNAL=7777is an environment variable mocking a real Edgegap deployment, telling your game server the internal port to listen on for player connections.
☑️ Once you’re happy with your configuration hit Start Local Server. Completing this step will result in a new container being started on your development machine.
☑️ Now it's time to connect your Unreal Engine Editor (PIE) game client to your local server container. Open Unreal PIE console with ~ (tilde) and connect with open <ip>:<port>:
ip=localhostor127.0.0.1(equivalent in most cases),port= randomized external port value of the container in Docker GUI.
☑️ Once you’ve verified you’re able to connect to your local server container and play without issues, you may delete the container 🗑️ to free up resources on your machine for other programs.
✅ You may now proceed to the next step.
☁️ 4. Publish to Edgegap
It’s time to ship your server online! Now that your image can successfully host players, we can upload it to Edgegap and start running it anywhere in the world. In this guide, we’ll be using Edgegap’s Container Registry (storage for images).
☑️ Choose an application name to label and group similar images on Edgegap.
☑️ Select the image tag you wish to publish and Upload Image. Completing this step will result in uploading your server image to Edgeap Registry and a new Application version being created in your web browser. Make sure to create your port mapping when prompted, with the default values.
Found a bug and need to rebuild/publish again? Use Rebuild from Source to Getting Started - Servers and Getting Started - Servers with the current extension input values quickly.
✅ You may now proceed to the next step.
🚀 5. Deploy to Cloud
This is the final step in this guide, after which you will have a server deployed on Edgegap cloud, to which players from anywhere in the world can connect.
☑️ Choose an application and version from previous step to deploy.
☑️ Once you’re ready, hit Deploy to Cloud, wait to reach 3. Deployment Ready. Completing this step will result in a new Deployment being started on your Edgegap account.
☑️ Verify there are no new errors in your console output. Ensure also that your Container Logs don’t show any errors and your Container Metrics don’t indicate 100% resource utilization (vCPU or memory), otherwise new player connections may be rejected, or your server stuck in a restart loop. See troubleshooting steps below to address any issues.
☑️ Now we’ll perform the final test and connect your Unreal Engine Editor to your cloud deployment. Grab your Deployment’s Host in place of server IP and the Deployment’s external port, open Unreal console in game client (tilde ~) and type open {host}:{port} .
Disable VPN when testing for more realistic conditions and receive a low-latency deployment.
☑️ Once you verify you’re able to connect to your Deployment without issues and are done testing, Stop your Deployment to free up capacity in your account for the next build.
In case you encounter issues, inspect Dashboard logs of your deployment.
If you can’t figure out the issue, we’re hanging out in our Community Discord and happy to help.
🙌 Congratulations on your first Deployment on Edgegap! If you’d like to learn more, keep reading.
👉 Next Steps
Once you have a working client/server setup, make sure to save a copy of your project (using version control software like git) so you can always trace back your steps in case you run into issues.
Continue reading to learn more about topics related to server lifecycle and discoverability.
Stop Deployments
Learn about various methods to stop deployments once the match concludes and players leave. Connect your Endpoint Storage to get your deployment logs, otherwise they will be deleted!
Injected Variables
Read useful information like deployment ID, server IP address, server location, and more; by accessing injected environment variables. Each deployment automatically includes:
Deployment Variables - automatically supplied by Edgegap,
Matchmaking Variables - automatically supplied by Edgegap when using Matchmaker,
App Version Variables - custom key-value pairs configurable by you.
Verify if the current instance is a game client or server by checking if Edgegap variable is set:
if (
FPlatformMisc::GetEnvironmentVariable(TEXT("ARBITRIUM_REQUEST_ID")).empty()
)
{
// client code
} else {
// server code
}Profiling Servers
To understand and optimize server performance issues on Edgegap, explore Container Logs, Container Metrics, and more Dashboard Monitoring tools at your disposal.
You can also use existing Unreal Engine profiling tools with Edgegap:
Insights require adding Port Mapping for your trace recorder (listens on
1981),allows using Unreal Engine Profiler for your server in real time,
alternatively, upload your trace record from store to external storage for offline analysis.
Matchmaking
Starting your Deployments manually, pasting URL and ports will not cut it for a live game.
Read more about Matchmaking to deploy automatically, just in time, when players come online.
Optimize Server Builds
Configure asset chunking to isolate client-only assets from server assets.
Explore Asset Chunking techniques and recommendations by Epic.
Exclude assets and plugins which are client-only, and not required for server to run.
Learn about build-time asset and plugin exclusion.
Review your content cooking strategy.
Consider Cooking on the Fly (COTF) to delay cooking client assets and speed up server builds.
Implement Level Streaming to reduce runtime memory load.
If your design keeps players mostly together in the same map area, level streaming may cut down your server's memory usage by more than 60%, and improve client performance!
Only include what you absolutely need for your server to run.
Copying unused files in your images results in image bloat, longer uploads, slower caching speeds, and slower overall server startup. Review Docker image optimization suggestions.
Consider using multi-stage Docker builds (link).
Separate large server dependencies to a separate image to reuse in multi-stage builds. Docker will cache each layer and simply reuse the previous version and skip uploading this part unless specifically instructed to do so, saving you bandwidth and time waiting for the upload to finish.
If you’re not sure why one of your Dockerfile commands throws an error, try debugging locally. Create a new stage just before the issue happens (add a second
FROMcommand), use--targetto instruct the build process to stop at the problematic stage, and thendocker exec -it {container} /bin/bashto enter interactive terminal inside your container. Afterwards, you can use shell commands in your base image to investigate further (e.g.topon ubuntu).
Customize Server Image
We also support adding your own Dockerfile for users who need more control over their images due to build size optimization, extraneous dependencies, or requiring more complex startup process. We’ll now share a few “do it yourself” tips and best practices.
Always make sure you are working with a functioning server build.
Before assuming an issue is related to the custom Dockerfile, ensure your Unity server build can be started, and that the build process in Unity didn’t throw any exceptions or errors.
Always test locally before uploading.
Testing your image locally will save you lots of time while waiting for the upload to finish. It’s also entirely free ✨ as it doesn’t require any Edgegap resources.
When testing locally, make sure to set your internal port correctly:
docker run \ -p 7777/udp \ -e ARBITRIUM_PORTS_MAPPING='{"ports":{"gameport":{"internal":7777}}}' \ 'registry.edgegap.com/<repository>:<tag>'
Make sure you’ve got the basics down. Every Dockerfile needs a few essential commands:
FROM {image}is your base image, for Unity projects we usually use a long-term supported Linux, but any Linux-based base image will do. These are usually public images stored on dockerhub. Dockerfile reference here. Dockerfile reference here.COPY {source} {destination}to copy your linux server build from your host machine inside the image, so you can start it later on. Dockerfile reference here.USER {user}should follow after a useradd (ubuntu) command or equivalent, it’s best not to run everything asrootto be on the safer side. Dockerfile reference here.CMD {command}will be the last line, most likely calling aStartServer.shor some kind of startup script to make sure your server initializes correctly once everything is set up. Dockerfile reference here.do NOT use
VOLUME- you will not be able to mount any local storage this way on Edgegap, consider our Endpoint Storage feature instead and use an S3 bucket, see Endpoint Storage,EXPOSE 7777/UDPis not required! This will not actually make the internal server port available from outside the container, it's only a hint for the developer and the port needs to bepublished when testing locally with
docker run <image> -p 7777/udp,or mapped in Edgegap Port Mapping.
Delay declaration of parameters until latest possible moment. Configurability > composability due to long server build times. Apply this approach to Dockerfile commands to build and upload faster.
Scenario: you need to define parameters like deployment stage, version, game mode, map, player count per server, backup frequency, or similar.
Bad solution: creating a separate image for every combination of your parameters. You will spend all of your time rebuilding the images with very little benefits from this approach.
Better solution - substitute configuration parameters just in time:
deployment parameters - supplied just before the deployment is made - matchmaking selectors passed as environment variables, or your custom session management system passing environment variables at deployment time,
version parameters - shared for all deployments on an app version - deployment stage, artifact tag, third party secrets and endpoints, and similar; then
one single image - contains and loads all configuration options when launched.
Do NOT run databases on Edgegap deployments.
Edgegap deployments are not intended for long-running processes and may be terminated after a long period of runtime without prior notice. A database (even if distributed) running in this manner may be terminated and result in an irreversible loss of data. If you need a database, please consider a third party DBaaS.
Consider using our Managed Clusters for hosting databases and long running services.
Last updated
Was this helpful?