Container builds#

A container is a way of packing software and all its dependencies together in a single unit. Game Server Hosting (Multiplay) container builds allow you to package your game servers and their dependencies, build a container, and push it to the Game Server Hosting container registry.

You can create a container build through the Unity Cloud Dashboard by selecting Container image when you create a build. The Create build wizard walks you through adding a service account, adding the registry, and selecting an image. Refer to Create a build with a container image.

Game Server Hosting uses Docker container tags in the format <ImageName>:<ImageTag>. Game Server Hosting generates the correct name and tag for your build, and displays it to you in the Unity Cloud Dashboard when you create or update a container build.

docker tag <ImageName>:<ImageTag> registry.multiplay.com/4818982f-bb28-4c39-9d44-628204b6780e/1ae4de65-849d-4ff1-86fc-1de3bdfbd891/12788:v1

Container build requirements#

When you create a Game Server Hosting (GSH) build, you have several options for uploading your build file. One option is to use Docker and the GSH container registry to upload a containerized version of your build. However, your build container must meet specific requirements (in addition to the General requirements) before you can use a containerized build.

Create a container built with the base image#

The linux-build-image template container takes care of most of the additional requirements of using a container build. You can use the container by adding FROM unitymultiplay/linux-base-image:<tag> to the top of your Dockerfile, as the following code demonstrates.

FROM unitymultiplay/linux-base-image:<tag>

# copy game files here
# for example:
WORKDIR /game
COPY --chown=mpukgame . .

# set your game binary as the entrypoint
ENTRYPOINT [ "./gamebinary" ]

In the preceding example:

• Replace <tag> with the version of the base image to use. You can check the linux-base-image tags for a list of available tags.
• Set WORKDIR to the current working directory of the container process. Any actions to run processes or copy files are relative to the working directory.
• Set ENTRYPOINT to the executable that runs when the container starts. This entrypoint should be your game server binary.

For a simple example, refer to this Simple Game Server Dockerfile (Unity Multiplay examples on GitHub).

Create a container build from scratch#

If you prefer to create your Dockerfile from scratch, it’s your responsibility to ensure your container meets the following requirements.

The following code block shows a simple Dockerfile that meets these requirements:

# ======================================================== #
#                  Unity base image stuff                  #
# ======================================================== #

FROM ubuntu:20.04 AS mpuk

RUN addgroup --gid 2000 mpukgame && \
    useradd -g 2000 -u 2000 -ms /bin/sh mpukgame && \
    mkdir /game && \
    chown mpukgame:mpukgame /game && \
    apt update && \
    apt upgrade && \
    apt install -y ca-certificates
USER mpukgame

# ======================================================== #
#                    Custom game stuff                     #
# ======================================================== #

FROM mpuk AS game

# copy game files here
# for example:
WORKDIR /game
COPY --chown=mpukgame . .

# set your game binary as the entrypoint
ENTRYPOINT [ "./gamebinary" ]

Server.json file#

If you use the base container image, the server.json file is already mounted into your container. You can find the server.json file location by checking the container's home environment variable.

• For Linux containers, it's in the $HOME environment variable.
• For Windows containers, it's in the $HOMEPATH environment variable.