v0.0.65

CronCompose v0.0.65

The agent runs on Windows, a deploy card controls one app, and an unchanged
install or build is reused from a cache on the server.

Highlights

• Windows agent: Jobs, deploys, web terminal, connectors, ports, and tools work
  on Windows 10/11 and Windows Server 2019+. bash/sh scripts run under Git
  Bash so existing scripts carry over; powershell, pwsh, and cmd are new
  job interpreters.
• Release binaries: Each release attaches
  croncompose-agent-windows-amd64.exe, croncompose-agent-windows-arm64.exe,
  checksums.json, and SHA256SUMS. A Windows CI job (vet, tests, service install
  smoke test) gates the release.
• One-line install: The portal's Install on Windows command runs
  install-agent.ps1 from an Administrator PowerShell: download, sha256 check,
  enroll, and register the croncompose-agent service (LocalSystem, auto-start,
  restart on failure).
• Auto-update: Windows agents check GitHub every 6 hours and install newer
  releases from the checksum-pinned .exe; Settings → Updates also works.
  AGENT_AUTO_UPDATE=0 pins a version. Linux and macOS update as before.
• Windows parity: Resource limits through Job Objects (CPU, memory, max
  processes), whole-tree kill on timeout and cancel, ConPTY terminals
  (PowerShell), a Windows services connector, netstat-based Ports, winget or
  Chocolatey installs on the Tools page, pm2 resurrect at start, and embedded
  timezone data.
• One app at a time: Start, Skip, Stop, and Restart on a deploy card run that
  app's steps. Restart re-runs that app from install through health and leaves
  the others running. A shared PM2 ecosystem is narrowed to that app before
  start, so updating its env does not restart its siblings.
• Install and build cache: An unchanged lockfile restores node_modules or
  vendor instead of installing again. Unchanged source restores the binary or
  .next output. A source-only change still compiles, with the previous
  .next/cache warmed first. The cache is <project>/.cc-cache and is kept
  when old releases are pruned. Delete that directory to force a clean install
  and build.

Upgrade

Update the agent, control plane, and web together. The step buttons call a new
API, and caching and one-app restarts run in the agent.

1. Pull this tag on the control plane and restart it, so the portal shows the
   Windows install command and the per-app step actions.
2. Linux and macOS agents: update from Settings → Updates.
3. Windows: add a server and run its Install on Windows command, or let an
   existing Windows agent auto-update. Install Git for Windows first if you
   deploy apps or run bash jobs.

See docs/wiki/Windows-Agent.md for what differs on Windows.

v0.0.64

CronCompose v0.0.64

Redeploy restarts PM2/systemd into the new release, and deploy env (e.g.
FRONTEND_PORT) survives the releases layout instead of going missing or
getting overwritten.

Highlights

• PM2 restart on deploy — If a process is already online from a previous
  release, the agent deletes it and starts fresh under current/. Skipping
  start left pm_cwd on a pruned release and caused MODULE_NOT_FOUND /
  crash loops with no app changes.
• systemd restart — After enable --now, the unit is restarted so an
  already-active service picks up the new release.
• Stable .env on disk — Project and per-app env are written into the
  release and project base .env. Gitignored env that only lived in an old
  checkout is no longer lost after migrate/prune.
• Monorepo listen ports — Starting the frontend no longer rewrites shared
  PROXY_PORT when FRONTEND_PORT / BACKEND_PORT are present.
• Deploy env wins — Child process env overlays replace agent keys instead
  of appending duplicates that getenv could ignore.

Upgrade

1. Update/rebuild the agent on each deploy host (required).
2. Rebuild/restart the control plane only if you pull this tag there too.
3. Redeploy affected projects (or pm2 delete + start once) so processes run
   from current/ with the written .env.
4. Confirm in CronCompose project Env (or /opt/.../<project>/.env) that
   FRONTEND_PORT / BACKEND_PORT / PROXY_PORT are set as you expect.

v0.0.63

CronCompose v0.0.63

Deploy run progress no longer marks a real go build (or other build half) as
Skipped when install and build run in separate flow waves.

Highlights

• Flow install/build tracking — When the agent logs only the install half
  of a script (e.g. go mod download), the live rail keeps the planned build
  step and activates it when the build wave runs, instead of replacing the
  step list and leaving Build: Skipped.
• Wave completion — install: done closes only the active half; pending
  build waits for its own wave. Cleanup/release still finish any remaining
  command steps.

Upgrade

1. Rebuild/restart the web UI.
2. Redeploy a project whose flow has separate Install and Build waves — Build
   should show Done when the compile command runs.
3. Agent and control plane updates are not required for this release.

v0.0.62

CronCompose v0.0.62

Safari-friendly browser push: a Home Screen web app manifest for iPhone/iPad,
plus clearer guidance when push is not available in a Safari tab.

Highlights

• PWA manifest — display: standalone so Add to Home Screen installs a web
  app (required for Web Push on iOS/iPadOS 16.4+). macOS Safari 16+ still works
  in a normal tab.
• Safari subscribe hardening — VAPID applicationServerKey is passed in a
  form Mac Safari accepts more reliably.
• Settings UI — When push cannot run (iPhone Safari tab, insecure origin,
  old browser), Settings explains why and, on iOS, how to Add to Home Screen.

Upgrade

1. Rebuild/restart the web UI (and control plane if it is not already on
   v0.0.60+ with web push).
2. Mac Safari: Settings → Browser notifications → Enable → Test.
3. iPhone/iPad: Share → Add to Home Screen → open that icon → Enable.
4. Agent update is not required for this release.

v0.0.61

CronCompose v0.0.61

When the connected branch moves ahead of the live deploy, the project page
offers an Update action.

Highlights

• Update deploy — The project detail page checks the remote tip of the
  connected branch against the last successful deploy. If new commits landed,
  an Update available banner shows how far ahead the branch is (when the
  provider reports it) and an Update deploy button starts a manual run on
  that branch. Rechecks about once a minute.

Upgrade

1. Restart the control plane and rebuild/restart the web UI.
2. Open a project whose connected branch has new commits — the banner appears
   when the tip differs from the live deploy SHA.
3. Agent update is not required for this release.

v0.0.60

CronCompose v0.0.60

Browser Web Push for deploys and updates, plus richer network interface details
in the UI.

Highlights

• Browser Web Push — In Settings, enable push on this device to get notified
  when a deploy starts, succeeds, or fails; when a job fails; or when a newer
  agent release appears — even if the CronCompose tab is closed. Requires HTTPS
  (or localhost). VAPID keys are auto-generated and stored in Postgres; optional
  VAPID_* env vars override them when you need stable keys across empty DBs.
• Networks interface details — An Interfaces overview (and wired / active
  Wi‑Fi drawers) shows IPv4/IPv6, gateway, DNS, MAC, method, and connection for
  each reported link. The active-link summary includes IP, gateway, and MAC.

Upgrade

1. Restart the control plane so migration 0026_web_push.sql applies and
   VAPID keys are ready. Rebuild/restart the web UI so /sw.js and Settings
   pick up the new push UI.
2. Open Settings → Browser notifications, allow permission, and enable push
   on each device you want woken.
3. Agent update is not required for this release (Networks uses fields
   agents already report).

v0.0.59

CronCompose v0.0.59

Deploy start/install now honors workdir .env ports and keeps listen aliases in
sync with the UI PORT field.

Highlights

• Workdir .env on start — Install and process start merge .env from the
  app directory (and parents). Deploy/UI values still win over the file.
• Listen port aliases — Setting PORT in the project UI also updates existing
  PROXY_PORT, HTTP_PORT, APP_PORT, LISTEN_PORT, and SERVER_PORT in that
  env. Fixes Peepal-style proxies that read PROXY_PORT and were still binding
  :80 (bind: permission denied) after the UI port was set to e.g. 3004.

Upgrade

1. Update the agent on each target (restart or reinstall).
2. Confirm the app’s UI PORT (and host .env if you keep one), then redeploy or
   Stop → Start the process so pm2 picks up the new env.
3. No control-plane or database migration required for this release.

v0.0.58

CronCompose v0.0.58

Tools cards and a logo loader polish the UI; pm2 under nvm lists processes again;
the bare domain always shows the marketing landing.

Highlights

• Toolchain cards — Tools page toolchains are equal-height 3-column cards with
  stacked Uninstall / Install (or Reinstall) rows and a full-width search bar.
• Brand loader — Logo-inspired loading mark (orbit, C draw, cascading slabs)
  used for route loading and common page placeholders across the app.
• Uniform deploy terminals — Per-process and Server terminal logs share a fixed
  280px height so Proxy / Backend / Frontend cards align regardless of log length.
• pm2 + nvm PATH — Agent pm2 commands (jlist, save, lifecycle) run through
  the toolchain prelude so #!/usr/bin/env node finds nvm Node. Fixes empty PM2
  lists and env: 'node': No such file or directory on save/startup.
• Site root landing — cron.workvar.com/ (and bare /) always redirect to
  /app/landing, signed in or out. Visiting /login with a valid session hard-
  navigates to /app instead of soft-routing to a 404.

Upgrade

1. Update agent, control plane, and web.
2. Restart or reinstall the agent on each target (pm2 toolchain PATH). Restart the
   control plane so / redirects to /app/landing.
3. Hard-refresh the UI (or clear cache) for Tools cards and the brand loader.
4. No new database migration.

v0.0.57

CronCompose v0.0.57

pm2 ecosystem names drive the Process name field and the deploy wait path, with a
clearer full-width run board.

Highlights

• Ecosystem process name — On deploy, ecosystem.config.js apps[].name
  wins over a computed project-app token. The control plane no longer sends
  that default for pm2, so waits match names like peepal-proxy.
• Auto-populate + edit sync — Inspect fills the Process name field from the
  ecosystem file and shows an “auto-populated” hint. Editing the field updates
  apps[].name in the ecosystem file on the next deploy.
• pm2 wait reliability — Each pm2 jlist call has a short timeout (no more
  forever hangs), with pm2 pid as a fallback. Start skips restart when the
  process is already online after Run.
• Run board layout — Waves are full width (no longer capped by the wizard
  deploy-flow max-width). The Server terminal is its own full-width row above
  the per-process terminals.

Upgrade

1. Update agent, control plane, and web.
2. Restart or reinstall the agent on each target (ecosystem name sync + jlist
   timeout). Restart the control plane so deploys omit computed pm2 names.
3. Existing projects: open Process manager, confirm Process name (re-detect if
   empty), save, then redeploy.
4. No new database migration.

v0.0.56

CronCompose v0.0.56

pm2 ecosystem files drive process names end-to-end, and the deploy run page shows
one terminal per process with a clearer wave flow.

Highlights

• Ecosystem autopopulate — Inspect reads ecosystem.config.* / pm2.json and
  fills process manager, process name, run script, and port. Multi-cwd ecosystems
  seed one block per app. process_name is stored and sent to the agent.
• pm2 wait uses the real name — The agent prefers apps[].name (e.g.
  peepal-proxy), starts with --only, and matches aliases / cwd so waits no
  longer time out looking for peepal-rp-proxy while pm2 registered something
  else. Parent-folder ecosystems (monorepo current/) are found too.
• One terminal per process — The run board shows Server plus each app’s own
  terminal. Phase tabs (install, build, run, start, …) filter that process’s log.
• Wave flow with arrows — Waves are a horizontal task graph: arrows between
  waves, parallel tasks side by side. Click a task to jump to that process and
  phase.

Upgrade

1. Update agent, control plane, and web.
2. Restart or reinstall the agent on each target (ecosystem name wait / --only).
   Restart the control plane so inspect returns pm2_apps and deploys send
   process_name.
3. Existing projects: re-detect the app folder or set Process name on the
   Process manager tab, then save — or rely on the agent’s ecosystem parse at
   start time.
4. No new database migration.