Getting started: use the template

gbandit scaffold gives you a working project that deploys as it is: a React, Vite and Tailwind frontend, plus a Rust (axum) backend with player authentication already wired up. The backend is opt-in, so deploys are frontend-only until you enable it.

Starting from a repo you already have instead? Read deploy an existing app.

1. Install the CLI

curl -fsSL https://github.com/gbandit/cli/releases/latest/download/install.sh | sh
gbandit login

gbandit login signs you in with Google in the browser. You can skip it: gbandit deploy then offers a guest account, which can deploy a frontend.

2. Scaffold

gbandit scaffold

You are asked for a title and a project slug. The slug becomes your subdomain: <slug>.gbandit.com. You can also pass them:

gbandit scaffold my-game --title "My Game"   # into ./my-game/, no questions
gbandit scaffold .                           # into the current directory

Scaffolding only writes files. Nothing exists on the platform until the first deploy.

3. Deploy

cd my-game
gbandit deploy

The first deploy creates the project and puts your game at https://dev-<slug>.gbandit.com. When you are ready for players:

gbandit promote                     # https://<slug>.gbandit.com runs what dev runs
gbandit project cover cover.png     # the image players see in the catalog
gbandit project publish             # list the game on games.gbandit.com

4. Develop

Change the code, run gbandit deploy, and refresh dev-<slug>.gbandit.com. The template's AGENTS.md sets coding agents up to work the same way.

Useful commands:

gbandit logs backend                # or frontend
gbandit env set KEY=VALUE           # config for your app
gbandit test-token 2                # a token to call your dev backend as a test user
gbandit docs                        # this documentation, in your terminal

5. Enable the backend

The template's backend is ready but is not deployed until you declare it: uncomment the backend block in gbandit.jsonc and deploy.

{
  "project": "my-game",
  "frontend": { "dockerfile": "frontend/Dockerfile", "context": "frontend" },
  "backend": { "dockerfile": "backend/Dockerfile", "context": "backend" },
}

Requests to /api/* on your game's domain now reach it, and player authentication works. To use it in the frontend, switch to the auth-aware routes marked in frontend/src/router.ts.

6. Add a database

Uncomment the backend's volume in gbandit.jsonc. The backend gets a disk and a SQLite DATABASE_URL. SQLite is the recommended choice; see Databases for why, and for managed Postgres.

{
  "project": "my-game",
  "frontend": { "dockerfile": "frontend/Dockerfile", "context": "frontend" },
  "backend": { "dockerfile": "backend/Dockerfile", "context": "backend", "volume": { "sqlite": true } },
}

Then uncomment the database wiring in the template, marked in backend/src/config.rs, backend/src/lib.rs and backend/src/main.rs. Migrations go in backend/migrations/, and the backend applies them itself when it starts; the platform never runs a migrator. The Dockerfile needs no change: its build step replays the migrations into a throwaway file so query! typechecks.

Where to go next

• Deploy contract: the full reference for gbandit.jsonc, routing, runtime limits, environment variables and git behaviour.
• Authentication: how the template's player auth works once the backend is enabled.
• The gbandit runtime: the script the template's index.html loads for the player's token, player counting and frontend logs.