Goose Is Not a Flisk Language. Here Is What to Run Instead

flisk resource api --type backend --language goose will not scaffold a Goose service. I checked the provider guide and the CLI readme. The registered backend languages are Python, Go, Rust, and Node. Omit --language and you still get Bun + Hono, byte for byte with the old scaffold.

If you meant the Goose programming language (memory-safe, no heap allocator, no GC), Flisk's own rule is explicit: a language without a provider uses --type bring-your-own and your Dockerfile. This post is that path, on a local stack only. Flisk does not deploy this.

What Flisk will and will not generate

A native provider also has to answer GET /health, read PORT, and bind every interface. A BYO service should do the same if you want the health URL Flisk prints to mean anything.

Scaffold the slot, not the language

npm install -g @flisk-sh/flisk
mkdir shop && cd shop
flisk project --yes
flisk resource ledger --type bring-your-own --stack shop --yes

That writes a service.json Flisk can route. It does not write Goose source. You own the compiler, the binary, and the image.

A minimal shape that matches how the other backends behave:

{
  "appName": "ledger",
  "appType": "bring-your-own",
  "stack": "shop",
  "port": 4010,
  "healthCheckPath": "/health"
}

Check the generated service.json before you edit it. Field names in a BYO resource follow the schema for that type, not the backend-provider schema. flisk doctor is the check, not this snippet.

Image contract

The Goose compiler is a native binary you put on PATH. The service container should not assume Flisk installed it.

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends curl ca-certificates \
  && rm -rf /var/lib/apt/lists/*
# Copy a Goose release that matches this arch, then your compiled binary.
COPY goose/bin/goose /usr/local/bin/goose
COPY ledger /usr/local/bin/ledger
EXPOSE 4010
HEALTHCHECK CMD curl -fsS "http://127.0.0.1:${PORT:-4010}/health" || exit 1
CMD ["ledger"]

Your Goose program has to:

1. Read PORT from the environment. Do not hardcode 4010 inside the binary and a different port in service.json.
2. Bind 0.0.0.0, not 127.0.0.1. Traefik is not on localhost inside the container network.
3. Answer GET /health with 200 before you call the stack done.

Flisk does not live-reload a BYO image. It did not generate that image, so it will not inject a watcher. Change Goose source, compile, rebuild the image, then let Tilt pick up the new container. That is slower than node --watch or Go's opt-in dev.liveReload. It is also the honest loop.

Run it

flisk up shop
# Flisk prints a health URL. Hit that, not a port you guessed.
curl -fsS http://api.shop.localhost/api/ledger/health

flisk up is local Docker + Tilt. Production stays on whatever you already ship (Helm, your own chart, something else). Do not treat the generated Dockerfile as the production Dockerfile. Flisk writes local wiring under .autogenerated/ and tells agents not to edit those files.

When not to do this

If the service is really a Go API, stop and use the provider:

flisk resource ledger --type backend --language go --stack shop --yes

You get go.mod, main.go, main_test.go, a multi-stage image, and an optional live-reload switch. Goose-the-language does not get that until someone lands a provider: one language per pull request, copy the Python provider, register it, add a Dockerfile template, keep Bun as the default. That is a Flisk contribution, not a flag you can pass today.

What I would not claim

• There is no goose id in the language registry.
• BYO has no Flisk live reload.
• A green curl on /health only proves the process is listening. It does not prove your Goose binary is the one you think you shipped.