Coming from Laravel, Django, or Next.js

Command cheat sheet

Your muscle memory maps almost one-to-one. The big difference: Grit's generate resource does in one command what Laravel splits across make:model, make:controller, make:migration, and a Filament resource.

The whole workflow, in grit

Like artisan or manage.py, the Grit CLI is the only interface you need — you never cd into a sub-folder or run raw go/pnpm to work on your app.

$grit new blog                 # scaffold the project
$cd blog
$docker compose up -d          # start Postgres, Redis, MinIO, Mailhog
$pnpm install                  # frontend deps (one-time)
$grit generate resource Post --fields "title:string,body:text,published:bool"
$grit migrate                  # create the tables
$grit seed                     # (optional) sample data
$grit start                    # run the API + web + admin together

Concepts that translate

Supported databases

Grit talks to your database through GORM, so the supported engines are PostgreSQL (production) and SQLite (dev, desktop, and tests). The Go API builds its connection string from the POSTGRES_* environment variables, or you can hand it a single DATABASE_URL and it will use that instead. Desktop apps default to a local SQLite file so they run with zero infrastructure.

# Option A — the API assembles the DSN from these
POSTGRES_HOST=localhost
POSTGRES_PORT=5432
POSTGRES_USER=grit
POSTGRES_PASSWORD=grit
POSTGRES_DB=blog

# Option B — one URL wins over the POSTGRES_* vars
DATABASE_URL=postgres://grit:grit@localhost:5432/blog
DATABASE_URL=sqlite:./app.db        # local file (desktop default)
DATABASE_URL=sqlite::memory:        # ephemeral, used by tests

Docker (what it runs, and why)

docker compose up -d spins up the infrastructure your app talks to — not your app. Think Laravel Sail: one command gives you a local Postgres, Redis, MinIO and Mailhog. You still run the app itself with grit start.

Docker is optional. Point the same env vars at hosted services — Neon or Supabase for Postgres, Upstash for Redis, Cloudflare R2 for storage — and you can develop and deploy completely Docker-free.

Architecture: MVC vs Grit

Laravel and Django are MVC — Model, View, Controller in one app. Grit keeps the same responsibilities but splits them cleanly: on the backend a thin Gin handler receives the request and calls a service that owns the business logic, which in turn works with GORM models. The “view” is a separate React frontend, fed by typed hooks generated from those same models.

Monorepos

The default Grit modes (triple, double, and mobile) scaffold a Turborepo monorepo — one repo holding every part of your product, with the Go→TypeScript types shared through a single package.

The single and api-only modes are flat instead of a monorepo. Either way it's one repo, shared types, and a single grit start.

Prisma vs GORM

Coming from a Node/Prisma world, the mental model carries over — only the tooling changes. Grit's ORM is GORM (Go).

So the end-to-end type-safety you loved from Prisma Client is still there — it just flows from your Go models out to the frontend instead of from a schema file.

GORM Studio

Grit ships a visual database browser — the equivalent of Prisma Studio, Adminer, or Django admin's data view. It's served by the Go API at http://localhost:8080/studio, and lets you browse and edit rows directly while developing, no SQL required.

Where to go next