Unity - Getting Started
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.
âď¸ Preparation
Before you get started, make sure to create a free account with Edgegap (no credit card required). You can invite your team members afterwards, even if they don't have an Edgegap account yet.
Configure a few essentials on your development machine:
âď¸ 1. Connect Account
âď¸ Sign in and verify there are no new errors in your Unity console related to Edgegap's plugin.
â You may now proceed to the next step.
đ§ 2. Build Game Server
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 to accomplish this with our plugin.
âď¸ Validate you have installed the required Unity Linux build tools.
âď¸ Edit Build Settings to ensure that all of your required game scenes are included.
âď¸ Optional: add netcode-specific script for port verification and environment bootstrapping to your initial server scene from Edgegap Server Hosting menu (right-click / â in your Hierarchy window).

Server builds should use address 0.0.0.0 and port 7777 in your netcode transport. If you customize your port please specify the same in your Port Mapping once you âď¸ 5. Upload to Edgegap.
âď¸ Once youâre happy with your configuration hit Build server, wait for the process to finish and verify there are no new errors in your Unity console. Completing this step will result in a new folder appearing in your project root - Builds/EdgegapServer/ServerBuild .
â You may now proceed to the next step.
đ 3. Containerize Server
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.
âď¸ Start by hitting the Validate button to ensure youâve completed âď¸ Preparation.
âď¸ You may configure the following options (or keep defaults):
Build path is the relative path to your server build artifact, letâs keep the default for now.
Keep builds inside your project folder, Docker only accepts relative build paths to project root.
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 default option for tagging, e.g.
2024.01.30-16.23.00-UTC.
Path to Dockerfile can be used to customize the recipe for your images.
We recommend keeping the default setting for now, you can read more later in section Customize Image.
Optional docker build parameters can be used to further instruct Docker on finer nuances.
We recommend keeping the default setting for now, you can read more later in Docker docs.
âď¸ Once youâre happy with your configuration hit Containerize with Docker, wait for the process to finish and verify there are no new errors in your Unity console. Completing this step will result in a new image appearing in your local machine. You can verify this either in Docker Desktop, in tab Images underneath Local (default), or in docker CLI by running docker images .
â You may now proceed to the next step.
đ§Ş 4. 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).
âď¸ You may configure the following options (or keep defaults):
Server image tag from the previous step.
Defaults to the last tag youâve built with the plugin.
Optional docker run parameters can be supplied for exposing multiple ports, or running your image on macOS machines.
You may publish multiple ports for your container if needed, simply add the parameter
-p {internal port}/{protocol}for each, for example-p 8080/tcp -p 7777/udpto publish and map your server port8080to a random external port for TCP connection and server port7777to a random external port for UDP connection at the same time. Find server port configuration in your Transport or netcode-specific settings.If youâre using a machine with ARM architecture (macOS M1, M2, M3, etc..) you should see this optional parameter included in your Optional docker build parameters:
--platform=linux/amd64.
âď¸ Once youâre happy with your configuration hit Deploy local container, wait for the process to finish, and verify there are no new errors in your Unity console. Completing this step will result in a new container being started on your development machine.
âď¸ Now itâs time to connect your Unity Editor game client to your local docker container to verify your server image is functioning properly. Find your netcode client settings and input:
localhostor0.0.0.0(equivalent in most cases) in place of server IP,randomized external port value found in Docker Desktop / Containers / edgegap-server-test.

âď¸ 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.
âď¸ 5. Upload 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).
âď¸ You may configure the following options (or keep defaults):
Application name on Edgegap can match your image name or be customized.
Weâve chosen to copy your image name for now.
Server image from step đ 3. Containerize Server.
Find any image name and tag stored on your machine in Docker Desktop / Images.
âď¸ Once youâre happy with your configuration hit Upload image and create App version, wait for the process to finish, and verify there are no new errors in your Unity console.
âď¸ You will be brought to our Dashboard, where you may configure optional settings. Completing this step will result in a new Application version being created, and your build artifact being tagged and uploaded to Edgegapâs Container Registry.
Application version on Edgegap can match your tag or be customized.
Timestamps are a great option for app version names, e.g.
2024.01.30-16.50.20-UTC.Multiple application versions may point to the same image tag, such as
v1.1.0anddev.Learn more about Apps and Versions later.
âď¸ You will now be prompted to define a Port for your new Application version. Make sure to set the same server port value as in step đ§Ş 4. Test Server Locally from your Transport or netcode-specific settings.
â You may now proceed to the next step.
đ 6. 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 Unity Editor game client to your cloud deployment. Input game client connection details from the Deployment's:
Host URL pointing to server's IP, usually in
NetworkManagercomponent.External port mapping to the server's internal listen port, usually in Transport component.

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
Once the match ends (or players leave), your deployment can be stopped to save cost. Running empty or only partially filled deployments can increase your cost unnecessarily!
Import our DeploymentAgent example from Unity SDK to stop servers easily and reliably.
Connect your Endpoint Storage to save 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 Matchmaking,
App Version Variables - custom key-value pairs configurable by you.
Import our DeploymentAgent example from Unity SDK to easily read strongly typed variables.
Session Automation
Starting your Deployments manually, pasting URL and ports will not cut it for a live game.
Automate popular game flows for managing sessions and scaling on demand with either:
Shorter Rounds
On-Demand Matches
Skill Rating and/or Custom Rules
Persistent or Rounds
Social Regional Hubs
Auto-Assign and/or Custom Search
Custom Backend:
Migrate Live Games
Optimize Builds
Rebuild only assets that changed since last build.
Consider using Unityâs Incremental Builds to speed up your build time.
Consider using Unityâs Incremental Builds to speed up your build time.
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.
Disable static batching of meshes to reduce image size.
Compress meshes to reduce image size.
Vertex compression does not impact image size.
Implement conditional lazy-loading of resources.
Exclude client-only assets by setting textures and meshes to CPU read/write disabled.
Consider using Unity Addressables for your client builds to speed up builds and deployments by loading assets just in time, or skipping loading some assets in server builds by checking for presence of Injected Variables.
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 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. You may optionally supply a path to your custom Dockerfile in step đ 3. Containerize Server. 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 server build can be started, and that the build process in your game engine 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:
Make sure youâve got the basics down. Every Dockerfile needs a few essential commands:
FROM {image}is your base image, 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?



