Building VelocityDrop: On-Demand Game Servers

VelocityDrop is an on-demand game-server concept: your friend group decides at 9pm to play Valheim, someone types a command in Discord, and a server exists by 9:02 — billed for the hours it actually runs, not the month.

This write-up covers the product thinking, the architecture, and — candidly — which parts are live and which are still behind the curtain.

The problem

Hosting a survival-game server (Valheim, Enshrouded, Palworld, and friends) is a terrible consumer experience. You either rent a monthly VPS that sits idle 90% of the time, or someone technical in the group babysits Docker on a spare machine. Friend groups don't play on a subscription schedule — they play in bursts. The pricing model and the interface are both wrong for how the product is actually used.

The product concept

Two convictions drive the design:

• Discord is the operating system of the friend group. Nobody wants another dashboard login. The server should be summoned from the place the group already coordinates — a bot command, a status embed, a "server's up" ping.
• Usage-based pricing is the honest model. Idle servers should hibernate. A group that plays eight hours a week should pay for eight hours, with their world state persisted between sessions.

Together they turn game hosting from "infrastructure you administer" into "a utility you summon."

Architecture

VelocityDrop is a monorepo with four surfaces, deliberately separated:

• The public site (velocitydrop.com) — Next.js on Vercel: positioning, pricing concept, and an interactive demo of the Discord flow.
• The Discord bot — command surface for provisioning, status, and lifecycle control.
• The API — game-aware provisioning and resource management (per-game images, save persistence, hibernate/wake logic), backed by Postgres via Prisma.
• The server manager — the piece that actually runs game containers on compute.

The separation is the point: the marketing site can be public and polished while the operator surfaces mature privately. The bot demo on the site is a pure browser mock — it exercises the real command grammar without touching live infrastructure.

Decisions and challenges

• Vercel for the site only. Game servers are long-running, stateful processes — the opposite of serverless. The site deploys from the monorepo's site/ directory; the backend services are documented as separate deployments and intentionally not exposed.
• Honest CTAs are a design constraint. An "Add to Discord" button that leads nowhere is worse than no button. The site's install CTAs render only when a real invite URL is configured; otherwise they become "try the demo" affordances with a "coming soon" marker.
• The hard problem is economics, not code. Fast cold starts and reliable save persistence are engineering work, but the make-or-break question is whether hibernation density makes usage pricing sustainable at small scale. That's a spreadsheet problem before it's a Kubernetes problem.

Current status

The public site is live at velocitydrop.com with the interactive demo. The bot, API, and server manager exist as working code in active development, run privately rather than as public production services. The next milestone is a closed pilot with a handful of friend groups — real usage data to validate the hibernation economics before opening it up.

It's a concept site backed by real architecture — and it stays clearly labeled as such until the backend earns its way to production.