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
| You pass | What you get |
|---|---|
| nothing | Bun + Hono |
--language python |
FastAPI, pyproject.toml, Python 3.12 image |
--language go |
net/http, Go 1.23 image, no live reload unless you opt in |
--language rust |
axum, image rebuild on change |
--language node |
node:http, node --watch
|
--language goose |
failure, no files written |
--type bring-your-own |
your image, your process, Flisk routes it |
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:
- Read
PORTfrom the environment. Do not hardcode 4010 inside the binary and a different port inservice.json. - Bind
0.0.0.0, not127.0.0.1. Traefik is not on localhost inside the container network. - Answer
GET /healthwith 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
gooseid in the language registry. - BYO has no Flisk live reload.
- A green
curlon/healthonly proves the process is listening. It does not prove your Goose binary is the one you think you shipped.
Top comments (0)