Build and publish opencode container image to Forgejo registry #52

New issue

Open

opened 2026-08-22 20:52:15 +00:00 by lab · 0 comments

lab commented

2026-08-22 20:52:15 +00:00

Owner

Part of the remote OpenCode design: an always-on opencode web server in the
K3s cluster, reachable from a phone via the router's existing Tailscale subnet
route. This issue covers approach A — the container image is built manually on
a laptop and pushed to the Forgejo registry; cluster manifests only reference
the pinned tag.

Tasks

Create k3s-ha-cluster/opencode/docker/Dockerfile. Base node:22-slim,
pin the current stable opencode-ai version at build time:

```dockerfile
FROM node:22-slim

ARG OPENCODE_VERSION=<pin-at-build-time>

RUN apt-get update \
    && apt-get install -y --no-install-recommends git curl ca-certificates \
    && rm -rf /var/lib/apt/lists/*

RUN npm install -g "opencode-ai@${OPENCODE_VERSION}"

RUN useradd -m -u 1000 opencode
USER opencode
ENV HOME=/home/opencode
EXPOSE 4096
```

Build and push from the laptop:

```bash
docker build -t git.yukselcloud.com/lab/opencode:v1 \
  -f k3s-ha-cluster/opencode/docker/Dockerfile \
  k3s-ha-cluster/opencode/docker/
docker push git.yukselcloud.com/lab/opencode:v1
```

Record the pinned version in the Dockerfile ARG default so the tag is
reproducible.

Acceptance criteria

Image visible in the Forgejo registry as git.yukselcloud.com/lab/opencode:v1
docker run --rm git.yukselcloud.com/lab/opencode:v1 opencode --version
prints the version as user opencode

Known ceiling (approach A): image bumps are a manual rebuild. If that gets
annoying, a follow-up issue can add a kaniko/buildx step to the Forgejo
workflow.

Part of the remote OpenCode design: an always-on `opencode web` server in the K3s cluster, reachable from a phone via the router's existing Tailscale subnet route. This issue covers approach A — the container image is built manually on a laptop and pushed to the Forgejo registry; cluster manifests only reference the pinned tag. ## Tasks - [ ] Create `k3s-ha-cluster/opencode/docker/Dockerfile`. Base `node:22-slim`, pin the current stable `opencode-ai` version at build time: ```dockerfile FROM node:22-slim ARG OPENCODE_VERSION=<pin-at-build-time> RUN apt-get update \ && apt-get install -y --no-install-recommends git curl ca-certificates \ && rm -rf /var/lib/apt/lists/* RUN npm install -g "opencode-ai@${OPENCODE_VERSION}" RUN useradd -m -u 1000 opencode USER opencode ENV HOME=/home/opencode EXPOSE 4096 ``` - [ ] Build and push from the laptop: ```bash docker build -t git.yukselcloud.com/lab/opencode:v1 \ -f k3s-ha-cluster/opencode/docker/Dockerfile \ k3s-ha-cluster/opencode/docker/ docker push git.yukselcloud.com/lab/opencode:v1 ``` - [ ] Record the pinned version in the Dockerfile `ARG` default so the tag is reproducible. ## Acceptance criteria - Image visible in the Forgejo registry as `git.yukselcloud.com/lab/opencode:v1` - `docker run --rm git.yukselcloud.com/lab/opencode:v1 opencode --version` prints the version as user `opencode` > Known ceiling (approach A): image bumps are a manual rebuild. If that gets > annoying, a follow-up issue can add a kaniko/buildx step to the Forgejo > workflow.