Skip to content

Capabilities

Capabilities are self-contained modules that add specific functionality to your project. Each provides template files, configuration, and wiring code.

verikt ships with 65 capabilities across 10 categories.

REST API with a full middleware chain and structured error responses.

Built on Chi v5. What you get: Chi router, middleware chain (RequestID, RealIP, Recoverer, OTel), RFC 7807 Problem Detail error responses, pagination helpers, OpenAPI spec, handler patterns with request/response types.

Suggests: rate-limiting, auth-jwt, cors, health, request-id

gRPC service with buf tooling.

What you get: Protocol Buffer definitions, buf configuration, server setup with interceptors, reflection for development.

GraphQL API with gqlgen code generation.

What you get: gqlgen config, schema definition, resolver scaffolding, playground for development.

Suggests: auth-jwt, observability, health, docker

WebSocket server support.

What you get: WebSocket upgrader, connection management, message handling patterns.

Requires: http-api

Server-Sent Events for real-time streaming.

What you get: SSE handler, event formatting, client connection management, heartbeat support.

Requires: http-api

Backend-for-Frontend gateway — aggregates and shapes backend service responses for a specific client.

What you get: Service aggregation patterns, response shaping, backend client abstractions.

Requires: http-api · Suggests: circuit-breaker, retry, observability, cors

Cross-Origin Resource Sharing middleware.

What you get: CORS middleware with configurable origins, methods, and headers.

Requires: http-api

Token bucket rate limiter.

What you get: Rate limiting middleware, per-endpoint configuration.

Requires: http-api

Context-based timeout middleware for HTTP handlers and service calls.

What you get: Timeout middleware, configurable per-route timeouts, context cancellation propagation.

Requires: http-api

API versioning support.

What you get: Version routing, header/path-based versioning strategies.

Requires: http-api

PostgreSQL database with connection pooling and health checks.

Uses the pgx driver directly. What you get: Connection setup, pool configuration, health checks, repository scaffold.

Suggests: migrations, docker, uuid

MySQL database with connection pooling and health checks.

Uses database/sql with the MySQL driver. What you get: Connection setup with pool configuration, health checks, repository pattern scaffold.

Suggests: migrations, docker, uuid

MongoDB connection with collection abstractions and repository pattern.

Uses the official Go driver. What you get: Client connection, database/collection abstractions, repository pattern, BSON helpers.

Suggests: docker, health, observability

SQLite database for embedded or single-node applications.

Uses modernc.org/sqlite — pure Go, no CGO required. What you get: Database connection, query helpers.

Suggests: migrations

AWS DynamoDB document database client.

What you get: DynamoDB client setup, table operations, query builders, config for region/endpoint.

Requires: config · Suggests: docker, observability

Redis connection and repository pattern.

Uses go-redis. What you get: Connection management, repository pattern scaffold.

Suggests: docker

Elasticsearch client with index management and search helpers.

What you get: Client setup, index lifecycle management, search query builders, bulk operations.

Suggests: observability, docker

AWS S3 object storage client.

What you get: S3 client setup, upload/download operations, presigned URLs, multipart upload support.

Requires: config · Suggests: docker, observability

Versioned database schema changes with up/down migrations.

Uses golang-migrate. What you get: Migration runner, up/down migration files, version tracking.

Suggests: docker

Data access abstraction with a base implementation covering common CRUD operations.

Uses Go generics for type-safe repositories. What you get: Generic repository interface and base implementation with common CRUD operations.

Suggests: postgres, mysql

Fluent SQL query builder for Go — type-safe query construction without string concatenation.

Uses Squirrel. What you get: Query builder setup, QB() helper with PostgreSQL-aware placeholder formatting ($1, $2), examples for SELECT/INSERT/UPDATE with dynamic WHERE clauses.

Suggests: postgres, mysql

Compile SQL to type-safe Go code — write .sql query files, get generated Go functions.

Uses sqlc. What you get: sqlc.yaml config, example .sql query files with annotations, sqlc generate wired into the build, generated Go functions with full type safety at compile time.

Suggests: postgres, mysql, migrations

Kafka consumer with handler pattern.

What you get: Consumer group setup, message handler interface, graceful shutdown with drain, config for brokers/topics/consumer group.

NATS messaging with JetStream for pub/sub and request-reply.

What you get: NATS connection, JetStream setup, publisher/subscriber abstractions, durable consumers.

Suggests: health, observability

In-process domain event bus with publish/subscribe pattern.

What you get: Event publisher, subscriber interface, async event dispatch.

Transactional outbox pattern for reliable event publishing.

The default approach — publishing events directly after a database write — loses events when the process crashes between the write and the publish. The outbox pattern fixes this by writing events to the same database transaction, then relaying them asynchronously. AI agents default to direct publishing because it’s the obvious implementation; the outbox capability and its guide context explain why the relay exists and how it works, preventing the subtle data-loss bug before it’s written.

What you get: Outbox table, publisher, relay worker for at-least-once delivery.

Suggests: postgres, event-bus, scheduler

Saga orchestrator for distributed transactions.

What you get: Saga definition, step executor, compensation logic, state persistence.

Requires: event-bus · Suggests: observability, outbox

Background worker/job processing.

What you get: Worker pool, job interface, graceful shutdown support.

Circuit breaker pattern for external service calls.

What you get: Circuit breaker wrapper with open/half-open/closed states, configurable thresholds and timeouts.

Retry logic with backoff strategies.

What you get: Retry wrapper with exponential backoff, jitter, max attempts configuration.

Concurrency limiter using semaphore pattern for load isolation.

What you get: Semaphore-based concurrency limiter, configurable max concurrent operations, timeout support.

Suggests: observability, circuit-breaker

Idempotency key support for safe retries.

What you get: Idempotency middleware, key storage, duplicate detection.

Requires: http-api · Suggests: redis

Standalone graceful shutdown manager.

What you get: Signal handling, ordered shutdown with timeouts, component registration.

Conflicts: platform (platform includes its own shutdown manager)

JWT authentication middleware.

What you get: Middleware that validates JWT tokens, claims extraction into request context, route-level authentication.

Requires: http-api

OAuth2 client credentials and authorization code flow.

What you get: OAuth2 provider integration, token exchange, callback handler, session management.

Requires: http-api · Suggests: auth-jwt

At-rest encryption helpers using AES-256-GCM.

What you get: Encrypt/decrypt functions, key management helpers, field-level encryption for sensitive data.

Row-level tenant isolation with tenant context middleware.

What you get: Tenant middleware, context-based tenant propagation, query scoping helpers.

Requires: http-api, config · Suggests: auth-jwt, observability

Request ID propagation.

What you get: Request ID middleware, context propagation, log correlation.

Requires: http-api

Health check and readiness endpoints.

What you get: /health and /ready endpoints, component health registration.

Requires: http-api

OpenTelemetry traces and metrics.

What you get: OTLP/gRPC export, trace propagation, metric collection.

Audit logging for sensitive operations.

What you get: Audit log writer, structured audit events, configurable retention.

Resilient HTTP client with retry and observability.

What you get: HTTP client with retry, timeout, and observability built in.

Suggests: circuit-breaker, retry

Type-safe HTML templating with templ — server-rendered components.

What you get: templ setup, layout components, page templates, hot reload configuration.

Requires: http-api · Suggests: htmx, static-assets

HTMX integration for server-driven interactivity without JavaScript.

What you get: HTMX response helpers, partial rendering patterns, swap configuration.

Requires: http-api, templ · Suggests: static-assets

Static file serving with embedded assets and cache headers.

What you get: Embedded file server, cache-control headers, content-type detection.

Requires: http-api · Suggests: templ

Internationalization with message catalogs and locale middleware.

What you get: Message catalog system (YAML per locale), locale middleware (Accept-Language + query param), context-based locale propagation, fallback to default locale.

Suggests: http-api, email-gateway

Email sending with provider abstraction.

What you get: Email gateway interface, provider implementation, template support.

Suggests: i18n, mailpit

Local email testing with Mailpit.

What you get: SMTP provider implementing email gateway interface, Docker Compose service (SMTP :1025, Web UI :8025).

Suggests: email-gateway, docker

Command Query Responsibility Segregation.

What you get: Command/query bus, handler interfaces, separation of read and write models.

Domain-Driven Design building blocks.

DDD requires discipline about where domain types live and what they’re allowed to depend on. Without explicit base types, engineers default to plain structs with no identity or invariant enforcement, and AI agents have no signal about where domain logic belongs. ddd provides the base types and makes the boundaries explicit — the guide generated by verikt guide explains the rules to agents so they place domain logic in the right layer from the start.

What you get: AggregateRoot, ValueObject, DomainEvent base types, entity identity patterns.

Suggests: event-bus, repository, cqrs

The production infrastructure layer.

Every service needs config loading, structured logging, lifecycle management, and graceful shutdown. Most services implement these ad-hoc, inconsistently, and with subtle gaps — the logger that doesn’t redact PII, the shutdown that doesn’t wait for in-flight requests. platform implements them correctly once, as a composable capability every service gets the same way.

What you get: YAML config loading with capability-aware struct fields, lifecycle.App with ordered startup/shutdown, structured logging via slog, PII redaction log handler, live reload with .air.toml.

Suggests: docker, bootstrap

The Composition Root pattern.

The most common source of untestable Go services is dependency wiring scattered across main.go and init() calls. bootstrap moves all dependency wiring into internal/bootstrap/bootstrap.go — a single, explicit place where every dependency is constructed and injected. AI agents benefit most here: the guide makes the Composition Root wiring explicit, so agents add dependencies in the right place instead of reinventing initialization inline.

What you get: Thin main.go that calls bootstrap.Run(version), internal/bootstrap/bootstrap.go with all dependency wiring, partial injection points.

Requires: platform

Input validation with go-playground/validator.

What you get: Validation rules, error formatting, field-level validation messages.

Time-sortable UUIDs (UUIDv7) for database-friendly primary keys.

What you get: UUID generation, type-safe ID wrappers.

Feature flag evaluation with local config fallback.

What you get: Flag evaluator, YAML-based flag definitions, context-aware evaluation.

Requires: config · Suggests: observability

Cron-style periodic task scheduling.

What you get: Cron-like scheduler, job registration, configurable intervals.

Local development environment.

What you get: docker-compose.yml with service dependencies, .env.example for environment variables.

VS Code Dev Container for consistent development environments.

What you get: .devcontainer/devcontainer.json, Docker configuration, extension recommendations.

Suggests: docker

GitHub workflow and templates.

What you get: Issue templates (bug report, feature request), pull request template.

GitLab CI/CD pipeline configuration.

What you get: .gitlab-ci.yml with build, test, lint, and deploy stages.

Suggests: docker, linting, testing · Conflicts: ci-github

Bitbucket Pipelines CI/CD configuration.

What you get: bitbucket-pipelines.yml with build, test, and deploy steps.

Suggests: linting, testing, docker

Makefile with common development targets.

What you get: Makefile with build, test, lint, run, and clean targets.

Linting configuration with a curated rule set.

What you get: .golangci.yaml with curated linter set (errcheck, govet, staticcheck, bodyclose, noctx, and more).

Test utilities and example tests.

What you get: Test helper functions using testify, example table-driven tests, test fixtures pattern.

Pre-commit hook configuration.

What you get: Pre-commit hooks for formatting, linting, and test execution.