mikestefanello/pagoda: a Go full-stack starter kit with a generated admin panel

What Pagoda is, and the problem it removes

Starting a Go web application means assembling a router, an ORM, a session store, a template layer, a CSS build and an authentication flow before you write anything that belongs to your product. Pagoda's README frames the project as a base starter kit rather than a framework, and that distinction drives everything else: the code is copied into your repository, so you can delete or replace any part of it. The stated goal is to provide much of the functionality you would expect from a complete web framework while establishing patterns and structure for your application. The intended audience is a Go developer who wants server-side rendered HTML and does not want to run a separate JavaScript frontend. The README argues that Go alone can be a full-stack solution and that frontend libraries can supply modern behaviour without writing JavaScript or CSS. It goes further and claims you can avoid writing HTML as well, because views are Go code. If your team is fluent in Go and comfortable reading source instead of configuration, the premise holds. If you wanted a framework with a versioned upgrade path and a plugin ecosystem, this is a different kind of artefact.

The stack Pagoda wires together, and why swapping matters

The foundation is four backend choices and three frontend choices. Echo handles HTTP, Ent handles modelling and querying, and Gomponents builds HTML as Go components that render to HTML 5. On the frontend, HTMX adds AJAX and WebSocket behaviour through HTML attributes, Alpine.js composes behaviour in markup, and DaisyUI supplies component class names as a Tailwind CSS plugin with no JavaScript dependency. SQLite is the storage default. The README states plainly that you are not required to use any of these and that swapping them out will be relatively easy, which is credible because there is no interface layer forcing you to keep them. The go.mod file confirms the shape of that stack: entgo.io/ent, labstack/echo, maragu.dev/gomponents, mattn/go-sqlite3, gorilla/sessions and golang-jwt/jwt are all direct requirements, alongside viper for configuration and afero for filesystem abstraction. The trade-off is that convenience here is assembly, not abstraction. A framework hides its internals; Pagoda exposes them, and every internal you touch becomes your maintenance responsibility.

Installing Pagoda and creating your first admin user

The README's getting started path runs through the Makefile. The install target depends on ent-install, air-install and tailwind-install, so one command fetches the Ent code generation module, the air live-reload binary and the Tailwind CSS CLI. The Tailwind step downloads a platform-specific binary, and the Makefile derives the package name from uname output: darwin maps to macos with arm64 or x64, and linux maps to linux-x64. The Makefile comment says that if this detection is not working you should hard-code the package yourself from the Tailwind releases page.

make install

The Tailwind step also pulls daisyui.js and daisyui-theme.js. Once the tools are present, the README's getting started sequence continues with creating an admin account, which the Makefile exposes as a target. The truncated Makefile shows the target starting with `admin: ## Create a new admin user (ie, ma` before the text is cut off, so the exact argument form is not visible in the available text; check `make help`, which the Makefile implements by grepping its own comment-annotated targets.

make help
make admin

Starting the application and live reloading are separate README subsections. The repository ships .air.toml at the top level, which is the air configuration file, so `air` is the intended live-reload entry point rather than a custom watcher. Ent code generation is its own target, and new entities are created through the ent CLI via a make target that takes a name argument.

make ent-gen
make ent-new name=MyEntity

The README also documents auto-migrations and a separate test database under the database section, so schema changes are applied at startup rather than through a migration file you author by hand.

The admin panel is generated, and that shapes what you can build

The admin panel is the feature most likely to decide adoption, and it is also the one with the clearest boundary. The README's admin panel section has subsections for code generation, access, considerations and a roadmap. Code generation is listed first, which tells you the panel is produced from your entity definitions rather than written by hand. That is efficient when your models are ordinary CRUD resources and awkward when they are not: a generated panel reflects the schema, so any administrative workflow that spans several entities, needs an approval step, or requires a custom action has to be added outside the generator. The presence of a considerations subsection and a roadmap subsection in the README is itself informative. The author documents the limits rather than presenting the panel as finished. If your internal tooling is the product, treat the generated panel as a starting point you will edit, and budget for that editing. If your models are close to plain tables, the generator saves real time.

Views as Go code, and what that costs you

Pagoda renders server-side HTML through Gomponents, so pages, layouts and components are Go functions. The README devotes a section to explaining why Gomponents, and separate subsections cover layouts, pages, rendering, components, icons, node caching and flash messaging. HTMX support has its own subsections for header management, conditional and partial rendering, and the CSRF token. Forms get submission processing, inline validation and CSRF handling. The practical effect is that a designer who edits templates cannot work in the repository unless they are willing to read Go. There is no template file with placeholder syntax to hand over. In exchange, the compiler checks your markup construction, and partial rendering for HTMX responses is a function call rather than a template include. The README notes that node caching exists, which implies rendering cost is a concern the author has already thought about; it does not state a caching strategy or a performance figure, so treat that as a mechanism to inspect in the code rather than a claim to rely on.

Tasks, queues, cron, cache and files: the parts you would otherwise write

Beyond request handling, Pagoda includes background work. The tasks section covers queues, a dispatcher, and monitoring tasks and queues, and the dependency list shows mikestefanello/backlite as the queue implementation, which is the same author's library. Cron is a separate top-level section. Caching uses maypok86/otter, an in-process cache, and the README documents setting data, getting data, flushing data and flushing tags. Files cover uploads, static files with a cache-buster, public files and cache-control headers. Sessions come from gorilla/sessions with an encryption subsection. Authentication covers login and logout, forgot password, registration, admins, email verification, and an authenticated-user middleware. This is a broad surface for a starter kit, and breadth is the point: the alternative is writing each of these yourself. The cost is that each subsystem is a dependency you inherit, and the README's own framing is that you can swap any of them. Swapping a queue or a cache means rewriting the call sites, not changing one line of configuration.

Where Pagoda is the wrong choice

Pagoda is a poor fit when your application is a JSON API consumed by a frontend team that owns its own build. The entire project is organised around server-rendered HTML, and the HTMX and Alpine.js integration assumes the server returns markup fragments. You could strip that out, but you would be deleting the reason to choose this kit over assembling Echo and Ent yourself. It is also a poor fit when you need a stable upgrade path. Because the code lives in your repository, there is no dependency to bump that brings you new features; the release history shows v0.26.0 in July 2025, v0.27.0 in August 2025 and v0.28.0 in August 2026, and the last push to the repository was on 2026-08-14. Those releases describe the upstream template, not your copy of it. Merging changes from a later version into a codebase you have edited is manual work. Finally, the SQLite default is a starting point, not a scaling answer. The README notes that Postgres and Redis were originally part of the project before the text is truncated, so the current default is SQLite with an in-process cache, and multi-instance deployment is a problem you will have to solve yourself.

How Pagoda differs from Buffalo and from hand-assembled Echo

Go has other full-stack starting points, and Buffalo is the closest comparison in intent. Buffalo is a framework with its own generators, a defined project layout and a plugin ecosystem, and it expects you to work within its conventions. Pagoda's README explicitly rejects that posture, calling itself a starter kit rather than a framework and promising no strict patterns or interfaces to follow and no fear of lock-in. The difference is not cosmetic: with Buffalo you upgrade the framework and your code adapts; with Pagoda you own the code and upgrades are a diff you apply by hand. The second alternative is assembling Echo, Ent and a template engine yourself. That gives you exactly the dependencies you want and no inherited structure, at the cost of writing the session handling, CSRF wiring, authentication flows, queue, cache and file serving that Pagoda already contains. Pagoda sits between those two positions, and the honest description is that it is a large, opinionated code sample you adopt wholesale and then edit. If neither the framework path nor the from-scratch path appeals, that middle position is the reason to look at it.

Licence and maintenance cost

Pagoda is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The repository's top-level LICENSE file carries the terms. Because the code is copied rather than imported as a library, the licence travels with your fork, and you are responsible for keeping the notice intact. Nothing about MIT obliges you to publish your changes. The maintenance picture is unusual and worth stating plainly. The last push to the repository was on 2026-08-14, and the most recent release, v0.28.0, carries the same date, following v0.27.0 in August 2025 and v0.26.0 in July 2025. That is a slow cadence with a long gap between v0.27.0 and v0.28.0. Since you own the code, upstream activity matters less than it would for a library, but it does mean you should expect to resolve dependency updates yourself. The go.mod declares Go 1.25.0, so your toolchain needs to be at least that version, and the dependencies listed there are the ones you will be tracking.

Editorial conclusion

Adopt Pagoda if you want a server-rendered Go application where you can read and edit every line, and you accept that the admin panel is generated rather than hand-written. Skip it if you need a plugin ecosystem, a separate JavaScript SPA, or a framework that upgrades itself. Before committing, run make install and make admin on your machine, confirm the Tailwind and DaisyUI downloads resolve for your OS and architecture, and check that the Ent code generation step fits your schema workflow.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mikestefanello/pagoda on GitHub
4. README
5. Releases