Singo is a Gin starter kit that ships your user endpoints already written

What it is: a reference implementation, not a framework

Singo stands for Simple Single Golang Web Service, and the README states the purpose plainly: this project uses a series of popular Golang components, and you can use it as a foundation to quickly build RESTful web APIs.

It was renamed. The README announces that go-crud has officially been renamed to Singo, which matters if you have seen the older name or followed an older tutorial.

What ships in the box is the interesting part. Nine components are integrated: Gin as the web framework, GORM as the ORM with the project intended for MySQL, gin-contrib/sessions for session management, go-redis as the Redis client, godotenv for development environment variables, gin-contrib/cors as CORS middleware, httpexpect for API testing, basic i18n implemented in the project itself, and cookie-based sessions for login state with a note that you can switch to token authentication if needed.

Then there is the code that already exists for reference and reuse: a user model, and four endpoints. `/api/v1/user/register`, `/api/v1/user/login`, `/api/v1/user/me` which requires a session after login, and `/api/v1/user/logout` which also requires a session.

That framing is the key to reading the project correctly. It is a starter you delete, not a library you depend on. Its value is that it includes reusable authentication code and a structure intended as a foundation.

The folder layout is an opinionated MVC variant

Eight folders are pre-created, each with a stated responsibility, and the layering is specific enough to be worth quoting precisely.

`api` is the controller layer of the MVC framework, coordinating all parts to complete each task. `model` stores database models and database operation code. `service` handles more complex business logic, and the README argues modelling business logic there improves business code quality, giving user registration, top-ups and order placement as examples. `serializer` stores common JSON models and converts database models from `model` into JSON objects required by the API. `cache` contains Redis cache-related code. `auth` contains permission control code. `util` holds common utility helpers. `conf` stores static configuration files, with translation-related files under `locales`.

Two things follow from that list. The `serializer` layer is what keeps database structs out of your HTTP responses, which is the single most common source of accidental data leakage in a quick Go service. And separating `service` from `api` is what makes top-ups and order placement fit without the controller becoming a transaction script.

The repository root also shows two directories the README does not describe: `middleware/` and `server/`. Given the components, `middleware/` almost certainly holds the CORS and session wiring, and `server/` the route registration and HTTP listener, but the README does not assign them roles and it would be guessing to say more.

`main.go`, `go.mod`, `.env.example`, `.gitignore` and `LICENSE.md` complete the top level. Licence is MIT.

Environment variables, and the secret you must change

The project depends on a fixed set of environment variables at startup, and godotenv lets you set them from a `.env` file in the project root, which the README recommends for development environments.

The `.env.example` file at the repository root lists the whole set, and every line is commented with its purpose in the README:

DB_USER="db_user" # MySQL user
DB_PASSWORD="db_password" # MySQL password
DB_HOST="127.0.0.1" # MySQL host
DB_PORT="3306" # MySQL port
DB_NAME="db_name" # MySQL database name
DB_CHARSET="utf8" # MySQL charset
DB_PARSE_TIME="True" # Parse MySQL time values
DB_LOC="Local" # MySQL time zone
REDIS_ADDR="127.0.0.1:6379" # Redis port and address
REDIS_PW="" # Redis connection password
REDIS_DB="" # Redis database, from 0 to 10
SESSION_SECRET="setOnProducation" # Session secret. It must be set and must not be leaked.
GIN_MODE="debug"

The dependency versions in `go.mod` confirm which of those variables matter. `gorm.io/driver/mysql` and `github.com/go-sql-driver/mysql` are direct requirements, so the MySQL-specific keys such as `DB_PARSE_TIME` and `DB_LOC` are consumed by the driver. `github.com/redis/go-redis/v9` explains the three `REDIS_*` variables, with `REDIS_DB` documented as a database index from 0 to 10. `github.com/gin-contrib/sessions` accounts for `SESSION_SECRET`, and the README's comment on that line is unambiguous: it must be set and must not be leaked.

The shipped value is `setOnProducation` in both the example file and the README. It is a placeholder, and copying `.env.example` verbatim means shipping it.

One variable is absent from the README's annotated list but present in `.env.example`: `LOG_LEVEL="debug"`. The README does not describe what values `LOG_LEVEL` accepts or what consumes it.

Running it: Go 1.25, then port 3000

The changelog has two entries and both matter. API testing is now supported, and Go 1.25 is now supported with the instruction to install that Go version before using the project. The `go.mod` agrees, declaring `go 1.25.0`.

The Go Mod section gives the setup sequence. Dependencies are managed with Go modules, so you initialise a module named `singo` and let the toolchain resolve the rest on first run:

go mod init singo
export GOPROXY=http://mirrors.aliyun.com/goproxy/
go run main.go // automatically installs dependencies

The `GOPROXY` line is worth a note rather than blind copying. It points at an Aliyun mirror, which is useful behind a network where the default proxy is slow or unreachable, and it is a reasonable default for the audience this project addresses. It is not required, and if you run outside that network you should either unset it or set a proxy you trust, since every dependency download goes through it.

Starting the project is one command:

go run main.go

After the project starts it runs on port 3000, and the README says you can change that, pointing at the Gin documentation for details rather than documenting a setting for it. The `.env.example` file does not list a port variable, and the README points to the Gin documentation for changing the port.

The module name in `go.mod` is simply `singo`, not a fully qualified path, which means this is intended to be forked and renamed rather than imported as a dependency.

The built-in API tests need their own database

API testing is the newest feature and the part with the most specific setup, so it is worth following exactly.

The tests use httpexpect, which appears in `go.mod` as `github.com/gavv/httpexpect v2.0.0+incompatible`. The `+incompatible` suffix means the module has not adopted semantic import versioning, so you cannot select a later major version of it without changing the import path.

The procedure has four steps. First, be in the project root directory. Second, create a test-specific environment file in the `test` directory:

cp test/.env.example test/.env

Third, modify the variables in `test/.env` so MySQL and Redis connect normally. Fourth, run from the project root with `-v` first to confirm the tests are actually running:

go test -v ./test

and once that looks right, drop the flag and check they pass:

go test ./test
ok      singo/test      (cached)

The separate `test/.env` is the important design point. Tests get their own configuration file, so a test run can point at a different database from development without editing the root `.env`. But it also means the test file is created by copying an example, which means the values are placeholders until you change them, and a run against misconfigured credentials fails at connection time rather than at an assertion.

The `(cached)` in the README's sample output is Go's own test caching, not part of the tool.

Where this starter stops helping

Three limits are visible in what the README includes.

The datastore is fixed. GORM is an ORM tool and the project is intended to be used with MySQL, and `gorm.io/driver/mysql` is the only driver in `go.mod`. Every model, query and the eight `DB_*` variables assume it. A project on Postgres is not adapting this starter, it is porting it.

Authentication is cookie-session based. The README says login state is stored with cookie-based sessions and that you can switch to token authentication if needed. That second clause is doing a lot of work: switching means rewriting the `auth` folder and both session-protected endpoints. A mobile or API-first client should probably not start here. The README links a separate repository as a token-based mobile login example built with Singo, which tells you the switch is real work someone has already done once.

i18n is basic. It is described as basic internationalization functionality implemented in this project, with translation files under `conf/locales`, and `gopkg.in/yaml.v2` in the dependency list. That is enough for a handful of strings, not a pluralisation or locale-negotiation framework.

On maintenance, the repository is not archived and the last push was on 2026-05-31, but it has no GitHub releases, so there is no tagged version to depend on and nothing to diff against when you upgrade. A starter you fork and delete sidesteps most of that, which is the main argument for treating Singo as code to copy rather than a dependency to import.

Editorial conclusion

Adopt Singo when your next project is a small Go REST API with MySQL, Redis and cookie sessions, and you want a working reference implementation to delete rather than an architecture to adopt. Do not adopt it for a service with different data stores, a token-first mobile API or a different Go version, since MySQL, Redis and cookie sessions are baked into the model, service and auth folders. Before starting, replace `SESSION_SECRET` and check `GIN_MODE`, because the example file ships a placeholder secret.

Frequently asked questions

Official sources

1. gourouting/singo on GitHub
2. Issues
3. License: MIT
4. README