Problem
fern generate --local can't use Apple's container runtime. On Apple Silicon / macOS, container is a common Docker-Desktop-free way to run OCI containers, but Fern only accepts docker or podman as the container engine, so there's no supported way to point local generation at it.
With only container installed and no Docker daemon running, local generation fails:
docker: Cannot connect to the Docker daemon at unix://<home>/.docker/run/docker.sock. Is the docker daemon running?
Error: Command failed: fern generate --local ...
The engine choice is hard-limited to two values:
- The
--container-engine flag is declared with choices: ["docker", "podman"] — command.ts#L745-L748.
- The underlying type admits only those two:
export type ContainerRunner = "docker" | "podman"; — types.ts#L35.
So even though Apple's container ships a CLI that mirrors the Docker verbs Fern uses (run, pull, rm), there's no accepted value to select it.
Why this looks like a small gap
Fern invokes the engine as a plain CLI subprocess, not through a Docker socket or client library. In runDocker.ts it spawns runner ?? "docker" directly — e.g. the image pull is execa(runner ?? "docker", ["pull", imageName]) at runDocker.ts#L183, with the default set at L152.
Because the engine is just execa(<runner>, ["pull" | "run" | "rm", …]), supporting Apple container looks like mostly: (a) adding "container" to ContainerRunner and the --container-engine choices, and (b) mapping any flag differences in the run invocation.
Current workaround, and why it isn't enough
Today the only route is to run a Docker-API-compatible shim in front of container and point DOCKER_HOST at it (e.g. socktainer), as described in #16715 — the same DOCKER_HOST trick used for OrbStack in #2392. It works, but it requires an extra always-on service and a non-obvious env var. It's a bridge, not first-class support.
This can't reasonably be pushed onto Apple's side, either: exposing a Docker Engine API in container core is not planned (apple/container#66). A Fern-side runner value is the clean fix.
Proposal
Add "container" (Apple's runtime) as a supported value for --container-engine and the ContainerRunner type, invoking the container CLI for pull/run/rm the same way docker and podman are invoked today. Happy to send a PR if the direction sounds good.
Problem
fern generate --localcan't use Apple'scontainerruntime. On Apple Silicon / macOS,containeris a common Docker-Desktop-free way to run OCI containers, but Fern only acceptsdockerorpodmanas the container engine, so there's no supported way to point local generation at it.With only
containerinstalled and no Docker daemon running, local generation fails:The engine choice is hard-limited to two values:
--container-engineflag is declared withchoices: ["docker", "podman"]—command.ts#L745-L748.export type ContainerRunner = "docker" | "podman";—types.ts#L35.So even though Apple's
containerships a CLI that mirrors the Docker verbs Fern uses (run,pull,rm), there's no accepted value to select it.Why this looks like a small gap
Fern invokes the engine as a plain CLI subprocess, not through a Docker socket or client library. In
runDocker.tsit spawnsrunner ?? "docker"directly — e.g. the image pull isexeca(runner ?? "docker", ["pull", imageName])atrunDocker.ts#L183, with the default set atL152.Because the engine is just
execa(<runner>, ["pull" | "run" | "rm", …]), supporting Applecontainerlooks like mostly: (a) adding"container"toContainerRunnerand the--container-enginechoices, and (b) mapping any flag differences in theruninvocation.Current workaround, and why it isn't enough
Today the only route is to run a Docker-API-compatible shim in front of
containerand pointDOCKER_HOSTat it (e.g. socktainer), as described in #16715 — the sameDOCKER_HOSTtrick used for OrbStack in #2392. It works, but it requires an extra always-on service and a non-obvious env var. It's a bridge, not first-class support.This can't reasonably be pushed onto Apple's side, either: exposing a Docker Engine API in
containercore is not planned (apple/container#66). A Fern-side runner value is the clean fix.Proposal
Add
"container"(Apple's runtime) as a supported value for--container-engineand theContainerRunnertype, invoking thecontainerCLI forpull/run/rmthe same waydockerandpodmanare invoked today. Happy to send a PR if the direction sounds good.