Beego's quick start builds an empty server, and every feature link points into the doc tree it calls old

The quick start compiles a server that registers no route of its own

The whole getting-started path is six commands and one small file.

mkdir hello
cd hello
go mod init
go get github.com/beego/beego/v2@latest

package main

import "github.com/beego/beego/v2/server/web"

func main() {
	web.Run()
}

go mod tidy
go build hello.go
./hello

Then the README points you at http://localhost:8080. The detail worth pausing on is what is absent: no handler, no route registration, and no configuration file anywhere in the sequence. web.Run() starts the framework, the framework picks port 8080 on its own, and nothing in the example maps a URL to your code, so the congratulations step is a live process serving an empty route table. The build step also names a single file rather than a package, so the shape of the project is one main package until you add directories yourself.

The primary doc site is labelled unavailable, and a third-party mirror is the fallback

The Quick Start section lists the documentation before it lists any code, and the first entry is titled New Doc Website with the word unavailable attached to it. The rest are a backup site credited to flycash at doc.meoying.com, the source of the new docs in a separate beego-doc repository, the old documentation in beego/beedoc, and an examples repository. The README also warns that the HTTPS certificate is sometimes expired and you may get a NOT SECURE warning. The consequence is that the first address a new user is handed is the one the project itself flags as broken, and the fallback is a personal mirror. So read the code, the issue tracker, and the module source rather than planning around a docs site that may not answer.

Every feature and module bullet is a link into the old documentation tree

The feature list covers RESTful support, MVC architecture, modularity, auto API documents, an annotation router, namespaces, development tooling, and a full stack for web and API. Each of those bullets is a hyperlink, and every hyperlink resolves inside github.com/beego/beedoc, the repository the Quick Start section labels as the old documentation. The module list behaves the same way: orm, session, logs, config, cache, context, admin, httplib, task, and i18n all point at pages under en-US/module in that same tree. The consequence is a documentation split that runs the wrong way. The features you would evaluate beego on, annotation routing, automatic API documents, and namespaces, are documented in the tree the project treats as superseded, while the new doc site is the one currently unavailable. Confirm against the source before you rely on any of them.

The root module requires about forty packages, six of them database clients

go.mod declares module github.com/beego/beego/v2 and go 1.24.2, then lists roughly forty direct requirements. Among them are go-sql-driver/mysql v1.9.2, lib/pq v1.10.9, mattn/go-sqlite3 v1.14.28, redis/go-redis/v9 v9.8.0, gomemcache, couchbase/go-couchbase v0.1.1, and go.etcd.io/etcd/client/v3, alongside casbin v1.9.1, prometheus/client_golang v1.22.0, the OpenTelemetry packages, grpc, go-kit, and opentracing. The list lines up exactly with the module catalogue: the orm module is why the SQL drivers are there, and cache is why memcached, redis, and the other stores are. The consequence is that a hello world import of server/web still resolves a module graph that reaches a 2013 pseudo-version of beego/x2j and a couchbase client at v0.1.1, which is more graph than an application that wants a router and a controller ever asked for.

ORM tests require a MySQL container on port 13306 before they will run

The Makefile does not have a self-contained test target for the ORM. It brings up a database first.

test-orm-mysql5: ## Run ORM unit tests on mysql5.
	docker-compose -f scripts/orm_docker_compose.yaml up -d
	export ORM_DRIVER=mysql
	export ORM_SOURCE="beego:test@tcp(localhost:13306)/orm_test?charset=utf8"
	go test -v github.com/beego/beego/v2/client/orm

The compose file lives in scripts/orm_docker_compose.yaml, the credentials are baked into the target, and the port is 13306 rather than the standard 3306. The consequence is that verifying the ORM locally needs docker-compose, using the v1 command spelling, with a database already listening on a nonstandard port that has to be free. The file shown here also ends mid-recipe, and the target list after this one is cut off, so which other suites need services is not something the Makefile tells you at a glance.

The scaffolding tool lives in another repository, and so does the docs

Beego is not one repository in practice. The framework is here, under the v2 module path. The development tooling the feature list points to is a separate project at github.com/beego/bee. The new documentation is a third repository, beego-doc, and the old documentation is a fourth, beedoc, which is where the contribution guide link in the Community section also points even though this repository carries its own CONTRIBUTING.md at the root. The module catalogue is the fourth axis: orm, session, logs, config, cache, context, admin, httplib, task, and i18n are all inside this module rather than separate ones, which is why a single go get brings the database clients with it. The consequence is that a project built on beego has to track version alignment across the framework and the CLI, and gets no signal from this repository when the docs move.

The README says Apache 2.0 while the repository license field says nothing at all

The License section states that beego source code is licensed under the Apache Licence, Version 2.0, with a link to the license text, and a LICENSE file sits at the repository root. The license recorded in the repository's own metadata is NOASSERTION instead, so a tool that reads the license field rather than the file will find no grant to check. That is a small thing, but it is the sort of mismatch that stalls an internal compliance review for a framework that otherwise ships an explicit grant. The rest of the project's signals are current: the last commit is dated September 17, 2026, with releases v2.3.10 from April 2026, v2.3.9 from March 2026, and v2.3.8 from May 2025. The community channels are a Slack invite link and QQ group 523992905.

Editorial conclusion

Beego is worth a look if you want the batteries-included shape in Go: an ORM, sessions, cache, config, logging, i18n, and admin in one project rather than a dozen modules. It is a poor fit if you need documentation you can rely on from a single place, because the headline features are documented in the older doc tree the project still points at, and the quick start never shows a route or a config file. Before starting, read the module list to see which of the ten modules you actually want, and budget for the fact that the framework, the scaffolding CLI, and the docs live in three separate repositories.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes