gofasta serve

Starts the project’s HTTP server by delegating to the project’s own binary — go run ./app/main serve. No file watching, no Air, no reload on change. This is the production-shaped way to run the server; for the development loop use gofasta dev.

Usage

gofasta serve

Run it from the project root. gofasta serve defines no flags of its own, but because it shells out to the project binary, any flags the project’s own serve subcommand registers are forwarded through unchanged.

What it does

1. Loads .env from the project root into the environment. This matters: a scaffolded project keeps its database credentials, REDIS_URL, and similar in .env, and the library’s config loader reads from the process environment without loading .env itself. The CLI populates the environment before spawning so the child inherits everything it needs.
2. Spawns go run ./app/main serve with stdin, stdout, and stderr wired straight through, so the server’s logs stream to your terminal and Ctrl+C reaches the server.

Server configuration — host, port, environment, database, cache, queue — comes from config.yaml and its GOFASTA_-prefixed environment overrides, not from CLI flags. See the Configuration guide.

Endpoints

With the scaffold’s defaults (server.port: "8080"):

Run gofasta routes to see the actual registered REST surface for your project rather than the defaults.

Running it for real

go run compiles on every start, which is fine locally but wasteful for a long-lived deployment. In production, build once and run the binary:

go build -o server ./app/main
./server serve

The scaffold’s Dockerfile already does this — build the image and run it:

docker build -t myapp .
docker run -p 8080:8080 myapp

gofasta deploy wraps the whole path — build, ship over SSH, restart under systemd or Docker, and health-check the result before considering the release live.