The Studio

iScoot is co-founded by Abdul & Ayas Alzenki. The game, iScoot, is a multiplayer hangout experience set in a skate park. Players drop in, ride around together, and exist online with each other. There's no elimination, no objective loop demanding server-side precision at scale. The experience is social, casual, and built around presence. The demo is currently available on Steam while the game approaches Early Access launch.

That premise shapes everything about the infrastructure requirements. Sessions are small. Traffic is unpredictable. The priority is getting players into a session quickly, keeping the experience responsive once they're in, and keeping the costs viable for an indie game.

The Challenge

iScoot's previous provider used a fleet model, which meant it needed to maintain full servers at all times. This had iScoot bear the cost of idle servers, which is an expensive way to run a game where sessions are small and casual by design.

As Abdul describes it:

"Unity's Multiplay, prior to the service's divesting to a third party, was expensive for the way our game works because we had to keep too much idle capacity around."

Beyond cost, the team needed something genuinely operable without backend infrastructure experience. That meant clear documentation, a matchmaker that integrated naturally, and no requirement to build orchestration logic from scratch. Abdul evaluated several services, spending days on each before getting stuck.

The Solution

Edgegap's modern, container-based orchestration enables game developers with match-bound sessions to deploy each game server just-in-time, spinning up exactly when the game server is requested and shutting it down when the session ends, optimizing usage and costs. This is unlike traditional fleet-based hosting, where studios reserve and pay for clusters of full virtual machines or bare metal nodes whether players are using them or not.

For iScoot, this unlocked something specific: the ability to run servers at a fraction of the size that fleet-based platforms require. Because Edgegap's containerized infrastructure can allocate a portion of a vCPU rather than a full node, sessions for a small social hangout game can be sized to match the actual workload.

"It let us run servers that are about 10x smaller than what we were using, which is a much better fit for iScoot."

Small, drop-in sessions running only when players are present, billed only for what they use. Which was a perfect fit for iScoot's development reality.

The migration itself reflected what a small team actually needs from an infrastructure partner. The documentation covered the fundamentals without requiring Abdul to develop background knowledge in distributed systems. The matchmaking and deployment pieces connected in a way that made intuitive sense.

"Edgegap made the migration practical. The docs were good, the matchmaker and deployment pieces made sense, and we got it working in about a day. Before that, we tried a few other services for a couple of days each and kept getting stuck."

Conclusion

iScoot's migration helped the studio find an orchestration service which matched its game's scope and business reality. A social hangout title with small, drop-in sessions doesn't need large reserved instances. It needs servers that start when players arrive, stop when they leave, and cost nothing in between.

Edgegap's just-in-time, containerized orchestration delivered exactly that: servers running at a tenth of the size previously required, a migration that took a single day, and a cost model that, as Abdul puts it, "already looks like a better fit than what we had before."

As iScoot moves toward its Early Access launch, the studio can focus on what it was built to do, creating a fun, social scooter experience, while Edgegap handles the infrastructure underneath it.