v0.1.115

Features

• Interactive ply exec on the microVM (macOS). ply exec app sh used to
  hang there — the guest kernel had no pseudo-terminals, so a shell ran on a
  pipe with no tty. The kernel now enables UNIX98 PTYs, the guest init mounts
  devpts and runs a tty-requested command on a real pty (prompt, job control,
  Ctrl-C), and the client raw-modes the terminal, forwards keystrokes, relays
  the merged output, and passes window-size changes through. A real terminal on
  both ends gets this automatically; ply exec -t forces it (like
  docker exec -t); non-interactive still runs on pipes with stdout/stderr
  apart. Ships in the republished kernel keg (ply/microvm-kernel@1.0.3), which
  this ply pins. Linux (setns) inherited the caller's terminal already and is
  unchanged.

v0.1.114

Fixes

• The build stage ships CA roots, so HTTPS-fetching builds just work. The
  minimal builder base has no system trust store, and Go/Rust/git/curl use it
  (Node bundles its own), so fetching a Go toolchain, modules, or crates failed
  with x509: certificate signed by unknown authority. ply now embeds a CA
  bundle and injects it into every builder image over the /work mount,
  pointing SSL_CERT_FILE/GIT_SSL_CAINFO/CURL_CA_BUNDLE at it — no more
  per-project cacert.pem to build. (A build command that sets one inline still
  wins.) Runtime images still ship their own CA certs as before.

v0.1.113

Fixes

• The build stage recognizes Go and Rust projects. The builder-runtime
  detector only knew node/bun/deno/python/ruby, so a repo declaring go (or
  rust) fell back to the node builder — ply build on a Go project failed with
  go: not found. It now covers go/rust (and python3) too, so the builder image
  gets the interpreter the project actually declares.

v0.1.112

Features

• ply init writes a default [build] command for JS projects. A detected
  Node or Bun project gets command = "npm install" (or bun install), plus
  && … run build when package.json has a build script — so ply build
  installs deps inside the Linux builder for the target instead of shipping
  host-native node_modules. Other project types get a commented # command = …
  hint so the field is discoverable. Edit or delete the line freely.

v0.1.111

Changed

• The CD repo build and ply build's build stage are now one code path.
  build_from_repo (the git+/repo= deploy builder) now calls the same
  run_build_stage helper ply build uses, so both build inside an identical
  Linux builder image — no drift between "how it builds on the host" and "how it
  builds locally". No behavior change (same builder image, memory fence, runtime
  pin, and env).
• ply build no longer prints a spurious "packing nothing" line while
  building its internal <name>-builder image (that image is entrypoint-only by
  design). User-authored builds still get the no-include hint.

Notes

• The build stage handles native addons that ship prebuilt binaries
  (esbuild, bcrypt, most popular packages) — verified. It cannot yet compile
  a native addon from source: the debian@13 builder image has no
  gcc/make/python3, and the registry doesn't carry the compilers. Use a package
  with a linux prebuilt, or wait for a toolchain-bearing builder base.

v0.1.110

Features

• [build] command — ply build builds inside a Linux image, on any host.
  Declare a build step in the manifest ([build]\ncommand = "npm ci && npm run build") and ply build runs it INSIDE a builder image (debian@13 + the app's
  declared runtime) over a COPY of the source, then packs the result — so ply build on macOS (or any host) produces a correct Linux image with native
  addons compiled for the target, the way the CD/git+ path already did. Your
  working directory is never mutated. Without a [build] command, ply build
  is unchanged (and the v0.1.109 foreign-arch scan still backstops a stale local
  node_modules). On macOS the stage runs in the microVM backend (needs the
  kernel); Linux uses a namespace sandbox.

v0.1.109

Fixes

• ply build refuses foreign native addons instead of shipping a broken
  image. Packing a directory whose node_modules were built on another
  platform (classic case: npm install on macOS, then ply build for a Linux
  image) used to succeed and fail only at runtime when Node couldn't load the
  addon. Build now scans the *.node files it's about to pack and refuses a
  positively-foreign one (Mach-O, PE, or the wrong Linux arch), naming the file
  and pointing at a [build] step. Matching addons and pure-JS trees are
  unaffected; an unrecognized header is never a false refusal. (The CD/git+
  path already built inside a Linux builder image and was never affected.)

v0.1.108

Fixes

• A repo build now compiles against the interpreter it will run under. The
  builder image defaulted to node@24 while the runtime image used the app's
  own declared runtime — so a repo pinning node = "22" had its native addons
  built against 24's ABI and failed to load under 22 at runtime
  (NODE_MODULE_VERSION), a break that only surfaced after deploy. The builder
  now pins to the repo's own ply.toml runtime (node/bun/deno/python/ruby)
  when the deployment doesn't set runtime= explicitly, so build ABI == run
  ABI. Repos with no ply.toml were already consistent (build and run share the
  detected recipe).

v0.1.107

Fixes

• Rotating a secret now restarts the service that reads it. A secret_env
  value change (or adding/removing a key while others remain) leaves the
  member's --env-file PATH unchanged, so the systemd unit was byte-identical
  and the running process kept its old environment until it happened to restart.
  Reconcile now folds a hash of the secret env-file's CONTENT into the unit
  (# ply-secrets-rev: … — the hash, never a value), so a rotation changes the
  unit text and triggers a restart. Scoped to .secrets/ files; units with no
  secret env-file are byte-identical to before (no restart on upgrade).

v0.1.106

Features

• Operator-injected secrets: secret_env on a deployment or stack member.
  A secret_env = ["STRIPE_KEY", …] list names env-var keys whose VALUES live
  only in this host's secret store (.secrets/<stack>/, 0600), never in the
  deployment file, the systemd unit, git, logs, or events. On each beat
  reconcile looks each key up and injects it as a tainted value through the
  existing 0600 --env-file path — off the world-readable unit. No manifest
  [params] declaration and no {} reference required, so an operator can add
  a runtime secret to a service without touching the app. A missing value fails
  just that member (peers keep converging) with a message pointing at
  ply secret set; a key that is both env and secret_env is refused. For a
  single-app deployment secret_env and env_file can't both be set — the
  store owns the one --env-file slot (env_file stays the dev lane).
• ply secret rm MEMBER.PARAM (--deployments <stack> for the host store)
  — idempotent secret removal, for rotation and cleanup.