Goravel: a Laravel-shaped skeleton for Go web applications

What Goravel actually solves for a Go team

Go's standard library gives you an HTTP server and a router, and stops there. Everything else, migrations, queues, validation, sessions, mail, task scheduling, an ORM, has to be assembled from separate libraries with separate idioms. Goravel is a scaffold that picks those pieces and gives them one naming scheme. The README describes it as "a full-featured, scalable web application framework that provides a starting scaffold", and the module table lists thirty-odd components, from Artisan Console and Authentication through to Validation and View. The intended reader is stated plainly: the framework style is consistent with Laravel, "so PHP developers don't need to learn a new framework". That is the whole pitch. If you have never written Laravel, the value proposition shrinks to "a batteries-included Go scaffold", which is a much more crowded category. If you have, the payoff is that routes, config, facades and console commands already read the way you expect, and the learning cost is Go's type system rather than an unfamiliar framework.

How the skeleton is arranged: app, bootstrap, config, routes

The repository is a working application, not just a library. Top-level entries include app/, bootstrap/, config/, database/, routes/, resources/, public/, tests/, main.go and an artisan executable with .bat and .ps1 variants for Windows. The go.mod pins the framework and the swappable pieces as separate modules: github.com/goravel/framework v1.18.0 alongside github.com/goravel/gin v1.18.0, github.com/goravel/postgres v1.18.0 and github.com/goravel/openai v1.18.0. That split is the design decision worth noticing. The HTTP layer and the database driver are not baked into the framework; they are adapters you can replace, which is why the topic list mentions grpc and microservice next to web. Configuration comes from a .env file plus config/ files, and the .env.example exposes the surface area directly: APP_KEY, APP_DEBUG, APP_HOST, APP_PORT, SESSION_DRIVER, JWT_SECRET, DB_CONNECTION, GRPC_HOST, GRPC_PORT, MAIL_HOST and an AI_PROVIDER with OPENAI_API_KEY and OPENAI_BASE_URL. The presence of AI_PROVIDER in the default environment template is a sign of how the scaffold tracks its own package ecosystem rather than staying minimal.

Installing Goravel and running the first route

The README points to https://www.goravel.dev for documentation and does not inline install commands, so the scaffold itself is the install: you take the repository as your starting application and build from there. The Dockerfile in the repository shows the intended build shape. It uses a two-stage build, compiles with CGO_ENABLED=0 and static linking flags, and copies main, .env, public/ and resources/ into an alpine image. The docker-compose.yml builds that Dockerfile and maps port 3000 to 3000, which matches APP_PORT=3000 in .env.example. The compose file declares a single service named goravel, and its build context is the repository root:

version: '3'

services:
  goravel:
    build:
      context: .
    ports:
      - "3000:3000"
    restart: always

Building and starting that service is the first run; the container entrypoint is /www/main. If you would rather run it on the host, the repository ships an artisan binary and the framework provides an Artisan Console module for application management and automation; the README does not print the individual command names, so check the console page on goravel.dev before assuming a Laravel command exists under the same name. Before any of this, copy .env.example to .env and fill in APP_KEY and JWT_SECRET, because the template leaves both empty. For a database-backed first run, set DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME and DB_PASSWORD, since every one of those keys is blank in the example file.

Where the Laravel analogy stops being useful

The comparison page on goravel.dev exists because the mapping is imperfect, and the README links to it as "Compare With Laravel" rather than claiming parity. Two structural differences matter. First, Go has no equivalent of PHP's runtime magic, so the facade pattern that makes Laravel's static-looking calls work has to be implemented through the framework's own service container and Mock module; the README lists Mock as a component for creating "test mocks for facades and dependencies", which tells you facades are a real abstraction layer here and not a free syntax trick. Second, the module split means a Goravel application is only as complete as the adapters you install. The skeleton ships Gin and Postgres, but the framework's own documentation covers Fiber-style alternatives through separate packages, and the related searches around Goravel and Fiber reflect that people do swap the HTTP layer. The wrong tool case is a small service: if you need three endpoints and a database ping, pulling in a scaffold with sessions, mail, queues, localization and a view engine is dead weight, and the framework's conventions will not pay you back.

Alternatives and the real difference in approach

The closest comparison is Laravel itself, and the difference is not features but execution model. Laravel runs on PHP's request lifecycle with a persistent framework bootstrapped per request (or kept warm by Octane); Goravel compiles to a single static binary, which is why the Dockerfile can use CGO_ENABLED=0 and copy a bare executable into alpine. You trade PHP's enormous package ecosystem and hosting ubiquity for a single artifact and Go's concurrency model. Against a plain Go router such as Gin used directly, the difference is inverted: Gin gives you routing and middleware and leaves migrations, queues, validation and mail to you, while Goravel's README lists all of those as built-in modules with a Laravel-shaped API. Against a Go framework with a different philosophy, the distinction is that Goravel does not try to be idiomatic Go first. It tries to be Laravel in Go, and it says so. That is a legitimate choice, but it means code reviews will argue about facades and service containers in a language whose community mostly avoids both.

Maintenance, versions and the MIT licence

The repository is not archived, and the last push was on 2026-07-05, which is recent. Release history shows v1.18.0 on 2026-07-05, v1.17.3 on 2026-07-04 and v1.17.2 on 2026-03-15, so the cadence is uneven: two releases a day apart, then a gap of roughly four months. The default branch is v1.18.x, and the skeleton's go.mod pins framework, gin, postgres and openai all at v1.18.0. That alignment is convenient but it also means upgrading the framework is a multi-module operation, not a single version bump. The framework is MIT licensed, which is permissive and places few obligations on how you distribute a compiled binary; the repository also accepts sponsorship through Open Collective, which has no bearing on the licence terms. Nothing in the repository describes a long-term support policy or a deprecation schedule, so treat the release notes as the only upgrade signal you have. This is not legal advice; read the LICENSE file in the repository if your organisation has specific requirements.

Editorial conclusion

Adopt Goravel if your team already thinks in Laravel terms (facades, artisan, migrations, Eloquent-style ORM) and wants that mental model in Go, or if you are building an API plus gRPC service and want one scaffold for both. Do not adopt it if you want a thin router with no framework opinions, or if you need a stable release line: the default branch is v1.18.x and the skeleton pins github.com/goravel/framework v1.18.0, so every dependency moves with the framework's own release cadence. Before committing, run the scaffold, check that go.mod resolves github.com/goravel/gin v1.18.0 and github.com/goravel/postgres v1.18.0 against your own database setup, and read the compare-with-Laravel page on goravel.dev to see which Laravel features the project itself lists as missing.

Frequently asked questions

Official sources

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