Overview

HAMR exists for a common kind of Go app: server-rendered pages, forms, auth, a database, and just enough interactivity to keep the UI from feeling dead. That covers a lot of internal tools, admin apps, SaaS dashboards, and client portals.

Instead of spending the first few days reassembling templates, sessions, CSRF, migrations, and a dev loop, you start with those decisions already made. The code stays explicit, and you can replace pieces when your app needs something different.

If you want a frontend-first SPA stack or a giant extension ecosystem, HAMR is probably the wrong tool. It is intentionally narrower than that.

What you get

• Single binary — your whole app compiles to one Go binary, with embedded migrations and templates.
• Type-safe templates — Templ compiles your views into Go code with full IDE support.
• HTMX-first interactivity — vendored HTMX, Alpine.js, and Idiomorph; no npm install required.
• Session auth — Argon2id password hashing, cookie sessions, CSRF protection.
• PostgreSQL + migrations — pgx, sqlx, and golang-migrate, configured to retry on startup.
• Form validation — pure-function validators with HTMX per-field validation built in.
• Hot reload dev server — file watching, build orchestration, Docker Compose, all in one TOML file.
• Project guidance for humans and tools — generated projects include convention docs, including files that help AI assistants stay aligned with the codebase.

Philosophy

Monolith first

HAMR never asks you "microservices or monolith?" because the answer is always "monolith first". You can extract services later when you actually need them. This keeps your project simple, your deploys fast, and your debugging local.

Hypermedia is the default

HAMR is built around the idea that HTML over HTTP — driven by HTMX — is enough for most web applications. JSON APIs are first-class citizens, but they exist for clients that need them, not as a default for browser pages. The same handler serves both.

Identity belongs to you

HAMR's auth packages accept subject IDs as opaque strings. Your project decides whether users are identified by an integer, a UUID, an email, or a custom field. The framework never imports your User struct.

Scaffolding, not magic

HAMR generates code you can read, edit, and own. There's no DI container, no codegen DSL, no runtime reflection magic. When you read your own code, you understand exactly what's happening.

Quick start

If you already have Go installed, this is the shortest path to a running app:

# Install the CLI
go install github.com/FyrmForge/hamr/cmd/hamr@latest

# Scaffold a new project
hamr new myapp
cd myapp

# Start the dev server
hamr dev

Open http://localhost:3000 and you'll see your app running with hot reload, Templ templates rendering, and PostgreSQL connected.