Building images

jekyo up takes source to running without a registry account, a CI pipeline, or a push URL.

How a build works

For every service with build:, JEKYO:

1. Hashes the inputs: build context files (respecting .dockerignore), the Dockerfile (file or inline:), build args, and the target platform. The hash is the image tag.
2. Skips if unchanged: if the cluster's registry already has that tag, there is nothing to do. Whitespace-identical rebuilds are free.
3. Builds with docker buildx for the server's architecture. An ARM Mac deploying to an amd64 server cross-builds automatically; you never think about platforms.
4. Delivers over SSH: the image is streamed into the server's containerd (instantly runnable) and pushed into the cluster's private registry from the server side. Your laptop's Docker never needs to reach any registry, so there is nothing to log into and no insecure-registry configuration.

jekyo build      # build + deliver without deploying
jekyo images     # what's in the cluster registry
jekyo up         # build (if needed) + deploy

The private registry

Every JEKYO cluster runs its own registry (in kube-system, on the persistent storage path). Pods reference images as registry.jekyo.local/<app>/<service>:<hash>, a name only the cluster resolves, with credentials wired at install time. Nothing is ever pushed to a third party.

Dockerfiles: file or inline

services:
  api:
    build:
      context: .
      dockerfile: docker/api.Dockerfile

  tools:
    build:
      context: .
      inline: |
        FROM alpine:3.20
        RUN apk add --no-cache curl

inline: keeps small, single-purpose Dockerfiles inside the same file as everything else. No repo clutter for a three-line image.