Hi Gophers,
I’d like to introduce ZATRANO, an open-source Go application platform for building production-grade software.
The current v2 architecture is a significant redesign rather than a simple version upgrade.
The main idea is simple:
Go provides the language. ZATRANO provides the application platform.
Instead of putting every application capability into one framework core, ZATRANO separates the runtime foundation from the application ecosystem.
The Architecture
ZATRANO is split into two independently maintained Go modules: the framework module and the packages module.
The framework repository contains:
- a small runtime kernel
- dependency-neutral contracts
- application bootstrap
- CLI
- HTTP primitives
- routing
- middleware
- configuration
- dependency container
- lifecycle management
- core infrastructure
The packages repository contains optional application capabilities such as:
- authentication
- sessions
- validation
- database
- ORM
- queues
- notifications
- scheduler
- cache
- localization
- AI
- RAG
- agents
- OAuth
- WebAuthn
- billing
- OpenAPI
- GraphQL
- and other application services
The important part is that the kernel does not depend on the packages ecosystem.
The dependency direction is intentionally one-way:
Application → Framework → Contracts & Kernel
Application → Selected Packages
This keeps the runtime foundation small while allowing the application layer to grow independently.
Why Build It This Way?
One problem I wanted to explore is the growing gap between “a Go HTTP framework” and “a complete production application platform.”
Go gives developers excellent primitives, but a production application still requires decisions and integrations around authentication, sessions, database access, queues, caching, notifications, AI, security, configuration, lifecycle management, and many other concerns.
ZATRANO attempts to provide those capabilities without turning the kernel into a dependency-heavy monolith.
Another important principle is explicit enablement. An application only enables the packages it actually needs.
The goal is:
- Small kernel
- Stable contracts
- Strongly typed developer APIs
- Opt-in capabilities
- Explicit application boundaries
rather than one enormous framework core.
A New Application
A ZATRANO application can be created with:
zatrano new myapp
cd myapp
go run ./cmd/app serve
Packages can then be explicitly enabled as needed:
go run ./cmd/app package:enable auth
The platform also provides a kernel-only minimal mode for applications that want to start with an even smaller surface.
One Architectural Detail I’m Particularly Interested In
ZATRANO uses a dependency-neutral contracts layer as the public ABI of the kernel.
The intention is to keep the stable application boundary independent from implementation packages.
Conceptually:
contracts → stable dependency-neutral ABI
kernel/* → strongly typed implementation
From(app) → typed developer API
This lets the ABI remain small while keeping the actual developer experience strongly typed.
Repository
Framework: GitHub - zatrano/framework: A Go application platform for building production-grade software. · GitHub
Packages: GitHub - zatrano/packages: Official ZATRANO packages · GitHub
Feedback I’m Looking For
I’m interested in feedback from experienced Go developers, particularly around:
- Is this separation between runtime/kernel and application capabilities useful in Go?
- Where should the boundary between a framework kernel and an application package be?
- Does a dependency-neutral contracts/ABI layer provide meaningful long-term value?
- What would you expect from a production-grade Go application platform that existing frameworks don’t provide?
I’d particularly appreciate architectural criticism rather than just feature requests.
Thanks.