Source: https://gameye.com/glossary/containerisation/

---
title: "Containerisation | Gameye"
description: "Containerisation packages your game server, dependencies, and config into a portable image that runs consistently across local, cloud, or bare-metal infra."
---

# Containerisation

Containerisation is the practice of packaging your game server binary, runtime dependencies, libraries, and configuration into a single self-contained unit called a **container image**. The image runs identically on a developer’s laptop, a cloud VM, or a bare-metal server in a data centre — no “works on my machine” surprises.

## Why containerisation matters for game servers

Before containers, deploying a dedicated server meant provisioning a machine, installing the right OS version, installing dependencies, copying the binary, and configuring environment variables — all by hand, and repeated for every region you wanted to deploy to. A single missed library version could break a deployment silently.

With containerisation, the entire environment travels with the binary. You build the image once, push it to a registry like Docker Hub, and your orchestrator pulls and runs it anywhere in the world. The server that passed testing is byte-for-byte identical to the server your players connect to.

## How it works with Gameye

Gameye is built around containerised game servers. When you integrate with Gameye, you push your server image to Docker Hub or GitHub Container Registry (other OCI-compatible registries are available on request). Gameye preloads your image globally, so when your matchmaker requests a session, a container is running within half a second — no cold-start wait while an image downloads.

You never push images directly to Gameye. You push to your registry, Gameye handles distribution. Each application supports up to five image tags simultaneously, so you can run multiple versions in parallel for testing or staged rollouts.

## The portability benefit

Because your server is a container image, you’re not locked into any single infrastructure provider. The same image runs on Gameye’s bare-metal network, on AWS, or on your own hardware. If you need to switch providers or run hybrid infrastructure, your server binary requires no changes.

**See also:** [Containers](https://gameye.com/glossary/containers/) · [Docker](https://gameye.com/glossary/docker/) · [How Gameye game server orchestration works](https://gameye.com/how-it-works/)

Building a multiplayer game? Gameye hosts dedicated game servers: ship your server as a Docker container and start one per match with a single API call, in a region near your players.

[See how it works →](https://gameye.com/how-it-works/)

[Back to Glossary](https://gameye.com/glossary/)

## Related terms

- ### Docker

Docker is a specific piece of software that combines your game, libraries, and config files into a single container. [Read more](https://gameye.com/glossary/docker/)
- ### Containers

A container is a packaged, portable software unit. For game servers, it’s your entire server build — easy to deploy, replicate, and roll back. [Read more](https://gameye.com/glossary/containers/)
- ### Deployment

Deployment releases a game server build to live infrastructure — containerising it, pushing to a registry, and starting instances so players can connect. [Read more](https://gameye.com/glossary/deployment/)
- ### Orchestrator

An orchestrator automates game server lifecycle — starting sessions on demand, placing them in the optimal region, and shutting them down when matches end. [Read more](https://gameye.com/glossary/orchestrator/)
- ### Sandbox Environment

A sandbox is an isolated non-production environment for testing game server builds and integrations without affecting live players or production costs. [Read more](https://gameye.com/glossary/sandbox-environment/)