A service toolkit for modular Go backends

Authorization, scheduling, workers, events, transactions, migrations, file storage, structured logging and telemetry: ready to go, in Go, on Fiber v3 or chi, with generators. Without the kit hiding your dependencies from you.

Get started Coming from Laravel?Coming from Symfony?The kit on GitHub

Why gpsystem

Start Go without digging out the fundamentals

All the base functionality you meet on most sites is ready to go: no researching graceful shutdown, telemetry wiring or an error model before you write your first endpoint.

Fiber v3 or chi

Two first-class HTTP engines on the same chassis. You choose per project (--engine); your handlers get native fiber.Ctx or net/http, with no home-grown router abstraction wedged in between.

Authorization on two levels

JWT auth, role- and permission-based RBAC, plus a policy layer for when a role isn't enough: per-request ownership and state checks, failing closed.

Scheduling, workers, events

Events/listeners on asynq, a transactional outbox for guaranteed delivery, cron scheduling with leader election, firing exactly once even across replicas.

Transactions and migrations

The transaction travels in the context across repositories; migrations are embedded SQL with their own cmd/migrate binary. pgx or bun: selected by import, invisible to the service layer.

Observability by default

Monolog-style dev logs, OTLP traces, metrics and logs, Sentry error tracking grouped by errs code: wired with a single call, switchable via env.

Spec-first generators

TypeSpec contract → OpenAPI 3.0 → typed server code; spec/handler drift is a build error. Project, module, surface, handler, event, listener, job: each a single command.

It does not hide your dependencies

The types of fiber.App, chi.Router, pgx, bun and asynq live in the public API. The kit centralizes, it doesn't abstract: upstream documentation stays valid for you.