Deployment

The website is designed for Vercel. It can host the homepage, docs, changelog, account pages, login callback, and lobby invite pages.

Vercel website

Set the project root or build command so Vercel runs the Next.js app in packages/www.

Add the public Supabase URL and anonymous key in Vercel project settings. The profile page needs those values at runtime.

What deploys cleanly today

• Home page.
• Docs and changelog pages.
• Profile login and callback route.
• Lobby creation and invite instruction pages.
• Static metadata and robots file.

Create and invite pages

/create and /create/[id] are website helpers, not the game server. They can create a stable invite page, show the selected Multiplayer lobby variant, print the host command, and print the join command for friends. If the host is logged in, /create also stores owner-scoped lobby metadata in Supabase for later GM/cloud linking.

Players still need one running opendungeon-host process for live WebSocket play. The invite page should make that boundary obvious: Vercel can host the instructions for free, but it does not keep the current CLI lobby process alive.

What still needs infrastructure

The current multiplayer game host is a CLI WebSocket process. Vercel can describe and link lobbies, but it cannot keep a long-running game process alive as a normal static website page. Internet multiplayer needs a reachable host, a container/service, or a future browser realtime adapter.

Internet multiplayer path

The supported deployment story is explicit:

• Vercel hosts packages/www: docs, account pages, /create, /create/[id], /gm, changelog, and Supabase-authenticated profile flows.
• One opendungeon-host process owns each live game. For internet play, run it on a VPS, Docker host, Fly.io, Render, Railway, or another service that supports long-running TCP/WebSocket processes.
• The host should bind to 0.0.0.0, expose the selected port, and set --public-url to the reachable HTTPS or HTTP URL shown to players.
• Supabase stores profiles, cloud saves, world ownership, GM patch proposals, host snapshot archives, and approved asset metadata. It should not be treated as the current movement/combat authority.
• The website invite page stores owner-scoped lobby metadata and displays setup commands. It does not keep the live lobby process running.

For a private internet test:

The later browser-native path can replace this only when the browser client has an authoritative realtime adapter that preserves validated command-log semantics.

GM host archives

The logged-in /gm page can read a running opendungeon-host URL and save the current host snapshot to the selected GM world. The archive event includes connected players, co-op state, the latest host authority cursor, recent command results, recent action log entries, delivered GM patches, combat state, and sync warnings. These rows stay owner-scoped through Supabase RLS and give future GM tooling a durable action history without making Supabase the live movement authority.

Vercel Sandbox experiment

Vercel Sandbox is a plausible future path for player-owned internet hosting, but it should be treated as an experiment before it becomes the default. /create now stores the planned Sandbox host shape in Supabase metadata so the invite, GM console, and future provisioning job agree on the same lifecycle. The flow would be:

• The host player signs in to opendungeon, connects their Vercel account, and chooses a team/project that owns sandbox usage.
• The website creates a sandbox under that host account, starts opendungeon-host with runCommand({ detached: true }), and exposes the sandbox port as the lobby URL.
• Supabase stores the lobby id, owner id, sandbox id, host URL, mode, seed, GM world id, and cleanup status.
• Snapshots can warm the sandbox so dependency install and package setup do not happen for every game session.
• The website stops the sandbox when the lobby ends or expires.

The planned sandbox launch command is:

The limits matter for gameplay. Vercel documents a default sandbox timeout of 5 minutes, with configurable/extendable runtime up to 45 minutes on Hobby and 5 hours on Pro/Enterprise. Open ports are limited per sandbox. Installed system packages do not persist unless the prepared sandbox is snapshotted, and snapshot creation stops the sandbox that was captured.

That means the first implementation should stay opt-in:

• Keep LAN/VPS/Docker hosting as the supported path.
• Use Sandbox only for logged-in hosts who explicitly connect Vercel.
• Warn hosts about plan limits and session timeout before creating the sandbox.
• Keep a reconnect path when the sandbox expires.
• Always call cleanup and store cleanup state in Supabase.

References:

• https://vercel.com/docs/vercel-sandbox
• https://vercel.com/docs/vercel-sandbox/pricing
• https://vercel.com/docs/vercel-sandbox/sdk-reference
• https://vercel.com/kb/guide/how-to-install-system-packages-in-vercel-sandbox
• https://vercel.com/kb/guide/how-to-use-snapshots-for-faster-sandbox-startup

Release path

Changesets tracks package releases. Website changes can be deployed independently, but package versions still move through the repo release flow and generated changelog.