Every jetpack needs a little lift. A multiplayer city needs something else, too: a place for everyone to connect. Around here, we call that place the “sky.”
It is a fitting name for Jetpack Pals. While you are weaving between buildings, meeting friends on rooftops, or showing off your latest look, the sky helps everyone share the adventure. Behind that friendly name is a dedicated Unity server and a small collection of services, each handling a different part of getting pals together.
A sky we can all fly into
The shared Angel City connection runs through a dedicated server. That means the public city does not depend on one player keeping their game open to host everyone else. You join the sky, other pals join the same sky, and the server helps exchange the information that makes you visible to each other.
The server runs Unity on Linux in headless mode: no window, no graphics to draw, and no person sitting at the controls. It runs the game’s server side while your own device draws the city and handles your flight. We even had to make sure the server did not spawn a pilot for itself—our sky does not need an extra pal standing motionless on the launch pad!
The technology behind the clouds
Amazon Lightsail is where our sky actually lives. We run the dedicated Unity server on an Ubuntu instance in AWS’s Oregon region. Lightsail provides the virtual machine that stays available independently of any player’s computer; Unity runs the multiplayer session on that machine, and Caddy provides its secure WebSocket front door. Supabase separately handles accounts and saved data.
Unity and C# are the foundation of the game. Unity Netcode for GameObjects handles networked player objects and shared messages, while Unity Transport carries that traffic between your game and the server.
For the browser game, that connection uses secure WebSockets, or WSS. Caddy sits in front of the Unity server, manages the HTTPS certificate, and passes the connection through to the game process. It gives the browser a secure front door into the sky.
On the server machine, Linux and systemd keep the process running and restart it after a failure. We also keep logs and a deployment rollback path, because running a multiplayer game includes the less glamorous job of figuring out what happened when a connection goes wrong. Server updates and restarts can still interrupt a flight; a dedicated server is not a promise of uninterrupted uptime.
Supabase handles a different part of the experience: authentication, saved progress, and database-backed social information. Its Postgres database stores durable data, while the sky handles the live multiplayer connection. Your account and saved pilot should have a life beyond any one flight.
The website and browser delivery have their own pieces, too. Vercel serves the site, Vercel Blob stores browser-game release files, and GitHub Actions with GameCI builds the Unity WebGL player. Getting the game onto your screen and connecting you to other pals are separate jobs in the same journey.
Your jetpack should still feel like your jetpack
One of our biggest priorities is how flying feels. When you turn or boost, we want your own game to respond immediately. The current approach keeps your flight movement local and shares a networked representation of your pal with the other players.
That representation carries things such as your position, pilot name, and appearance. Your own view stays focused on your local character, while everyone else sees the networked version moving through their city. This also helped us grow multiplayer from the original flying game without rebuilding every single-player system at once.
There is a tradeoff: the current movement model trusts the player’s device to report its position. That suits the friendly exploration experience we are building now. Competitive systems and valuable rewards would need their own validation work; having a dedicated server does not automatically make every action server-verified.
Knowing who is up there
A name over a character’s head is useful, but it is not proof of identity. When a signed-in pilot connects, the sky checks their authentication token with Supabase and associates the verified account with that connection. Guests can still fly without an account; account identity is something we verify for the features that need it.
We also separate two useful questions. “How many pals are in this sky?” comes from a small status report published by the dedicated server. “Which pilots are online?” uses database-backed presence, so it can include someone enjoying a private flight as well as someone in the shared city.
A shared city and a private flight
The sky is the dedicated path into shared Angel City. Our friend-code flights use another part of the stack: Unity Gaming Services, including Authentication, Lobby, and Relay through the Multiplayer Services SDK. Those sessions let a player host a flight that friends can join.
The distinction matters. The dedicated sky runs independently of an individual player. A Relay-backed private flight has a player host and its own session lifecycle. Both support flying together, but they have different responsibilities behind the scenes.
Teaching the game and the sky to speak the same language
The browser game and dedicated server are built and deployed separately. Sometimes one gets an update before the other. We added a small protocol-version handshake so they can catch an explicit mismatch in the network messages they expect.
Instead of silently dropping a connection and making a broken session look like an empty city, the game can explain that the page needs refreshing or that Angel City needs to catch up. Clear messages matter just as much as the connection code when you are trying to meet a friend.
There is still plenty to refine as we build and test. But the goal stays simple: open the game, find your pals, and take off together. You enjoy the skyline. We will keep working on the sky behind it.