Goravel puts a Laravel-shaped structure on top of Go

A framework organised like Laravel, in Go

Goravel's premise is stated plainly: the framework style is consistent with Laravel so that PHP developers do not need to learn a new framework and can still work in Go. That is a deliberate design constraint rather than a side effect, and the repository layout shows it. The top level is a directory per concern, not a small set of packages: `auth/`, `cache/`, `console/`, `crypt/`, `database/`, `errors/`, `event/`, `facades/`, `filesystem/`, `foundation/`, `grpc/`, `hash/`, `http/`, `log/`, `mail/`, `notification/`, `packages/`, `process/`, `queue/`, `route/`, `schedule/`, `session/`, `telemetry/`, `testing/`, `translation/`, `validation/` and `view/`.

Two of those directories matter more than they first appear. `facades/` gives you a stable class-like entry point over the underlying services, which is how the Laravel habit of writing `Cache::` or `Queue::` style calls can carry over. `packages/` is the extension point for building reusable packages that add to the framework itself, and there is a separate documentation page for package development.

The module is `github.com/goravel/framework` and it requires a very recent toolchain. The `go.mod` file in the repository states the language version and the toolchain it expects:

module github.com/goravel/framework

go 1.26.0

toolchain go1.27.0

That combination is the first practical constraint for anyone adopting it. You are not free to target an older Go release and still build this dependency tree, which narrows who can host the application and when.

Twenty-eight modules, from routing to gRPC to task scheduling

The feature table is wide enough that the interesting question is where the boundaries are rather than what is present. Routing, controllers and middleware sit under Http. Data work is split three ways: a database query builder, an ORM described as an elegant implementation for database operations, and migrations for versioning schema changes. Factories generate fake model data for tests, seeders populate tables with test or initial data, and Migrate handles schema versioning.

Auth is split by mechanism, with JWT and Session drivers for identity verification, and authorization is permission-based using policies and gates. Sessions are managed across HTTP requests, validation uses rules against incoming request data, and views render HTML. Behind those sit the parts that decide whether an application is pleasant to run: a Cache with memory, Redis and custom drivers, a Queue for deferring time-consuming work to background processing, Task Scheduling with cron-like expressions, and an Event system for dispatch and listening.

Two entries stand out as unusual for a Laravel-shaped framework. The first is Grpc, a gRPC server and client implementation, which means a service-to-service transport sits in the same module as the HTTP layer rather than beside it. The second is Process, described as an expressive and elegant API around Go's standard os/exec package, which is how you would invoke external binaries from a scheduled job.

The breadth is the product. Goravel is positioned as a starting scaffold, a single dependency that supplies the conventional parts of a web application so you do not assemble them yourself.

Artisan console, testing utilities and mock generation

The Artisan Console is a CLI for application management and automation, and it is the piece that carries the Laravel analogy furthest in day to day work. Where Laravel developers expect `php artisan`, Goravel expects an equivalent console binary, and the presence of a `console/` directory plus a `contracts/` package suggests the interface is defined separately from its implementation, which is the same separation Laravel uses for its contracts.

Testing is treated as a first-class module rather than an afterthought. The Testing entry covers HTTP testing, mocking and assertion utilities, and the Mock module creates test mocks for facades and dependencies. The repository carries a `.mockery.yaml` file, so mock generation is configured in the project rather than assembled by hand in each test file.

There is also a `tests/` directory at the top level, and the dependency list includes `github.com/stretchr/testify` for assertions and `github.com/brianvoe/gofakeit/v7` for generating fake values, the same package the Factory module leans on to produce fake model data. `github.com/samber/lo` is present too, a functional-style helper library for collection operations.

The practical consequence is that a Goravel project carries a test toolchain comparable to what a Laravel project has, which is the strongest argument for the framework for a team arriving from PHP.

Configuration through files and environment variables

Configuration is described as application configuration management from files and environment, and the repository ships a `.env.example` at the top level. That file is the clearest window into the framework's expectations, and it is not short. The mail block covers host, port, username, password, from address and name, plus to, cc and bcc. Then come storage credentials for four different object stores, each with its own key, secret, bucket and URL pair: AWS, Aliyun, Tencent and MinIO.

Here is the first part of that file as it stands in the repository:

APP_KEY=

MAIL_HOST=
MAIL_PORT=
MAIL_USERNAME=
MAIL_PASSWORD=
MAIL_FROM_ADDRESS=
MAIL_FROM_NAME=

MAIL_TO=
MAIL_CC=
MAIL_BCC=

Two observations follow from reading the keys themselves. First, `APP_KEY` is empty in the example, which is the encryption key for the Crypt module, and an empty value there is the kind of thing that fails at runtime rather than at boot. Second, four storage providers are configured in parallel, which tells you FileStorage is built around multiple drivers with credentials resolved from the environment rather than from a single hardcoded target.

The dependency list confirms the configuration approach: `github.com/spf13/viper` for reading configuration and `github.com/go-viper/mapstructure/v2` for decoding it into structures, and `github.com/spf13/cast` for type conversion. The database layer uses `github.com/jmoiron/sqlx` and `github.com/Masterminds/squirrel` for query building.

Where the framework stops: telemetry, process execution and package boundaries

Three limitations deserve naming before anyone commits a quarter to this.

The first is that the documentation is thin at the edges. The repository ships a large feature table, but each entry links out to goravel.dev rather than explaining the behaviour in place, and the roadmap points to a GitHub issue list rather than a dated plan. You will be reading external documentation for most of the surface, and the documentation repository is a separate project that accepts pull requests, so the docs lag or lead the code depending on who is around.

The second is the release history. The three most recent releases listed are v1.18.0 on 2026-07-05, v1.17.3 on 2026-07-04, and v1.17.2 on 2026-03-15. The default branch is `master`, not `main`, and the last push to that branch was on 2026-10-19. A framework whose tagged releases are separated by months while the branch itself moves weekly means you are choosing between a stable tag that is several months old and untagged work on master.

The third is scope. Grpc sits inside a web framework, and the HTTP layer is the centre of the design. If your service is primarily gRPC with a small HTTP management surface, pulling in the whole framework to get a gRPC server is a heavier choice than using the gRPC libraries directly. The same applies to Queue and Task Scheduling: they are convenience wrappers, and a Go service that needs one cron-like task can schedule that itself.

The alternative: standard library plus a few focused libraries

The comparison the project itself points to is with Laravel, and there is a separate page for it. Comparing against Laravel is useful for judging the ergonomics, since the target audience is people who already know that framework, but it is not the choice most Go teams face. The realistic alternative is the opposite approach: use `net/http` for routing and handlers, pick a router such as the one from the chi or gin ecosystem, add `database/sql` with a driver for persistence, and wire in a job library only where one is needed.

The difference in approach is structural rather than feature-level. The standard-library-plus-libraries path gives you a dependency count you can read, an upgrade that touches only the packages you chose, and a Go version floor you set yourself. It also means writing the glue: session handling, validation, view rendering, mail dispatch and console commands, which is exactly the work the Laravel-shaped framework exists to remove.

Goravel's version gives you one module, a directory layout you already recognise, facades that make the service calls read like the ones you used before, and a console, ORM, queue, scheduler, cache and test suite in the same tree. Its cost is the dependency tree above, the Go 1.26 floor with a go1.27.0 toolchain directive, and the fact that a framework opinion about caching, sessions or validation is now your opinion, whether you wanted it or not.

For a team that arrives from PHP, that trade is usually worth it. For a team that already speaks Go idiom, it frequently is not.

Licence, governance and who the project is built for

The framework is open-sourced software licensed under the MIT licence, with the licence file at the top of the repository. That is the most permissive end of the range and carries no copyleft obligation for applications built on it.

The project describes itself as a full-featured, scalable web application framework that provides a starting scaffold to help Gophers build their applications quickly. The phrase worth unpacking is scaffold. Goravel is aimed at people who want the conventional parts of a web application already assembled, and the documentation site is the primary interface to it, with an example application kept in a separate goravel/example repository rather than inside the framework itself.

The contributor surface is stated as well: pull requests and issues are welcomed, there is a contribution guide in the documentation, and the project is funded through Open Collective with a Discord community linked from the README. The repository also carries `AGENTS.md` and `CLAUDE.md` alongside a `.coderabbit.yaml`, which indicates the project has made tooling for AI-assisted contribution part of its own configuration.

None of that tells you whether the API will shift under you. It tells you that the maintainers are reachable, and that the release cadence on master is active even where tagged releases are spaced further apart.

Editorial conclusion

Adopt Goravel if you are a PHP developer who knows Laravel's shape and want that structure in Go, or if you want routing, ORM, queues, scheduling and testing helpers in one module rather than assembling them. Do not adopt it if you need a gRPC service first and only a web layer second, or if you need a stable long-term release line: the most recent tagged release listed here is v1.18.0 from 2026-07-05, and the last push to the master branch was on 2026-10-19. Before starting, check the comparison page at goravel.dev against the Laravel version you already use, and confirm that the packages you would otherwise import yourself exist in the module list.

Frequently asked questions

Official sources

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