Skip to content

v0.18.10.

Complete release notes · 2026-10-29. Read upgrade instructions and runtime limits before deploying.

Includes the previously unpublished 0.18.5–0.18.9 changes. Existing tags are preserved.

Added

  • Commit statuses on GitLab, Gitea and Bitbucket Cloud (ROADMAP item 8). A service that clones through a token source of one of those types can mark each deploy on its commit (ninedeploy/<slug>: running, then success, failure or cancelled). Turn it on under Service → Settings, or with PUT /v1/services/:id/commit-status (service admin). The token goes only to the repository's own host, fork previews never report, and a failed status never fails a deploy. No migration.
  • Error-rate and latency alerts (ROADMAP item 7). Two new alert metrics, error_rate (percent of requests answered 5xx) and latency_p95 (ms), read the last 5 minutes of a service's traffic analytics. They are per service, need traffic analytics on, and skip a service with fewer than 20 requests in the window. A .ninedeploy manifest declares them as the alert triggers highErrorRate (thresholdPct) and slowResponses (thresholdMs). No migration.
  • Nodes created as DigitalOcean droplets (G4.3, after Hetzner). Servers → DigitalOcean takes a personal access token and creates a tagged droplet whose user data installs Docker and starts the agent. The node is rekeyed as soon as the agent answers, exactly like a Hetzner VM. Routes /v1/cloud/digitalocean/* (operator), SDK cloud.digitalocean. No migration.
  • Node Dockerfile builds take a build stage and build arguments (agent capability docker.buildOptions, agent 0.18.10). A stage used to be refused on a node and build arguments were left out. The values travel only inside a sealed request and are masked in the build output. An older agent keeps the old behaviour, and the log names the version to install. NINEDEPLOY_AGENT_BUILDS=off switches it off with the other node builds.
  • AI alert investigations (ROADMAP item 6), opt-in under Settings → AI assistant. When a service's alert rule fires, the panel sends the service's newest runtime logs (sanitized) and the alert to the configured provider, and shows the answer under the rule in Monitoring. At most 12 an hour; a protected lane is never investigated; notifications never carry the logs or the answer. No migration.

Fixed

  • Stop during a node deployment now fences delayed container creation, stops the selected and candidate generations, and retires only the interrupted candidates. A later deployment can start normally. Updated node agents advertise the required capabilities; older agents keep the handoff pending until upgraded.
  • ninedeploy tunnel kept nothing a client sent before the target was connected, so a client that speaks first (psql, an HTTP request) waited forever. This was certain on nodes and possible on the panel host. Node database tunnels were also refused as not running.

Source CHANGELOG.md at 6046cfe8