qor/qor: Go libraries for admin interfaces, publishing and e-commerce backends

What QOR gives a Go developer that a plain framework does not

A Go web framework gives you routing and middleware. It does not give you an admin screen for every table, a staging copy of your content, a state machine for order status, or per-locale rows in the database. QOR is a set of libraries that fills that gap for business applications, CMSs and e-commerce systems. The README describes the project as abstracting "common features needed for business applications, CMSs, and E-commerce systems", and it is explicit about the audience: QOR "is not a boxed turnkey solution", and the README says you need proper coding skills to use it. That sentence is the whole positioning. If you want to install a CMS and start typing articles, this is the wrong repository. If you are writing a Go service and you would otherwise spend a month on an admin CRUD layer, publishing workflow and role checks, the modules listed in the README are the ones you would have written. The project is a complete rewrite in Go of an earlier proprietary Ruby on Rails framework used internally at The Plant, and QOR 1.0 was the first version released under the MIT licence.

The module split: admin, publish, transition, media, worker, i18n, l10n, roles

QOR is not one package. The README lists the modules and links each to its own repository under github.com/qor: Admin, which the README calls "the core part of QOR system" and which generates an admin interface and RESTful API to manage your data; Publish, for a staging environment where content changes are reviewed before going live; Transition, a configurable state machine with states, events such as paying an order, and validation constraints on transitions; Media Library, for assets with several cloud storage backends and CDN publishing; Worker, a batch process scheduler; Exchange, for CSV or Excel import and export; i18n for managing and inline-editing translations; l10n for DB-backed models on a per-locale basis with locale-based querying; and Roles for access control. The root repository ties them together. Its go.mod requires github.com/qor/admin, github.com/qor/publish2, github.com/qor/roles, github.com/qor/sorting and github.com/qor/validations directly, and pulls in l10n, publish, worker, session, responder and others indirectly. That structure is the main design decision to understand: you are composing libraries, and the composition surface is Go code, not a config file.

Installing qor/qor and rendering a first admin screen

There is no installer and no CLI. The README points to the documentation at doc.getqor.com and to a live demo at demo.getqor.com/admin with source at github.com/qor/qor-example, which is the practical starting point for a first run. The module path is github.com/qor/qor, so you add it to a Go module the usual way:

go get github.com/qor/qor
go get github.com/qor/admin

The root go.mod targets Go 1.26 and requires a database driver, either github.com/go-sql-driver/mysql or github.com/lib/pq, plus github.com/jinzhu/gorm. QOR's admin layer is built on GORM v1, which matters when you pick your ORM. The frontend assets are built separately and the README states the requirement plainly: Node.js and Gulp, installed with

npm install && npm install -g gulp

From there the README gives two Gulp tasks. Running `gulp` watches SCSS and JavaScript changes, and `gulp release` builds the release files. The package.json confirms the toolchain: Gulp 5, gulp-sass 5.1.0, gulp-babel 8.0.0 and gulp-uglify. Expect to run the asset build whenever you touch the admin theme, and expect a Node toolchain in your build pipeline alongside the Go one.

Where QOR stops and your application has to start

The README's "What QOR is not" section is unusually direct for a project of this kind, and it is worth taking literally. QOR does not ship a working product. You define the models, register them with the admin module, write the routes, and configure roles, publishing and localization yourself. The live demo exists precisely because the libraries alone do not show you a finished system. The dependency graph is the second constraint. Several modules in go.mod resolve to pseudo-versions rather than tagged releases: publish2 at v0.0.0-20200729081509, roles at v0.0.0-20171127035124, sorting at v0.0.0-20200724034229, validations at v0.0.0-20171228122639. Pseudo-versions pin a commit, so builds are reproducible, but they also mean those modules have no release cadence you can follow. The root repository itself has three tagged releases, v1.1 in April 2019, v1.2.0 in June 2021 and v1.3.0 in November 2022. The last push to the repository was on 2026-09-01, so work continues between tags, but anyone expecting semantic-version releases for the whole stack will be disappointed.

Publishing, state machines and the cost of the GORM v1 dependency

Two modules deserve scrutiny before you commit. The first is publishing. The README describes Publish as providing a staging environment for content changes, and the go.mod requires github.com/qor/publish2 while github.com/qor/publish appears only as an indirect dependency. Both are present in the build graph, and the README does not explain the relationship between the two. If your application depends on the staging workflow, read both repositories before you design your content model, because the answer determines which package you import. The second is the ORM. QOR's admin and related modules sit on jinzhu/gorm v1.9.16, the older import path. GORM v2 lives under gorm.io/gorm with a different API. Choosing QOR therefore means either keeping that application on GORM v1 or running two ORM generations in one binary. That is a real architectural cost, and it is the kind of thing that only becomes visible after the first feature is working.

QOR against Django admin and Rails Active Admin

The closest comparisons are not Go projects. Django ships an admin application that inspects your models and generates CRUD screens with no registration code, and Rails has Active Admin and Administrate in the same tradition. QOR's admin module follows that model, generating an interface and a RESTful API from your data definitions, but it does so as a library inside a language whose web ecosystem is thinner. The difference in practice is the amount of glue. With Django you get an ORM, migrations, authentication and templates as one coherent package. With QOR you assemble the pieces: GORM for persistence, the QOR modules for the admin surface and workflows, and your own choices for the rest. That is a genuine trade. You get Go's deployment story, a single static binary and predictable concurrency, and you pay for it in assembly work. For a team already writing Go services, that trade is often worth it. For a team whose main problem is content editing, it usually is not.

Licence, maintenance and what an upgrade actually costs

QOR is released under the MIT licence, stated in the README and in the LICENSE.txt file at the repository root, and repeated in package.json for the frontend tooling. MIT is permissive: you can use the libraries in commercial and closed-source products, and the main obligation is retaining the copyright notice and licence text. This is a description of the licence, not legal advice; check the terms yourself if the distinction matters to your organisation. Upgrading is where the cost sits. The root module has three tags with multi-year gaps between them, so there is no steady upgrade train to ride. Because the modules are separate repositories, a change in admin can require a matching change in roles or validations, and the pseudo-version pins in go.mod mean you are tracking commits rather than releases for several of them. The repository includes update_all_qor_repos.sh and test_all.sh at the top level, which suggests the maintainers run the modules together rather than testing each in isolation. Budget for pinning your own dependency versions and reading diffs, not for a changelog that explains what moved.

Editorial conclusion

Adopt QOR if you are a Go developer building a custom admin or back office and you are willing to write the models, routes and configuration yourself; the modules for admin, publishing, state transitions, media and i18n cover a lot of ground. Do not adopt it if you want a finished CMS you can install and run, or if you need a vendor answering support tickets. Before committing, verify that github.com/qor/admin still builds against your Go version, check which of the indirect dependencies in go.mod are pinned to untagged commits, and read the publish and publish2 modules side by side, because both appear in the dependency list and the README only describes one of them.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. qor/qor on GitHub
4. README
5. Releases