Openship v0.9.0

Openship Actions brings repository CI to your own Linux and macOS servers and
Cloud runners. This release also lets you move your Openship control plane between
Desktop and a server, adds GitHub deployment Checks and shared notifications, and
improves Cloud build scheduling, routing, monitoring and webmail. These notes cover
all changes since 0.8.2.

Openship Actions

• Run CI independently of GitHub Actions — workflows in .openship/workflows/
  use GitHub-style YAML and run through Openship on selected destinations. Trigger
  them manually, on repository pushes or pull requests, on schedules, through
  authenticated dispatch, or from Jobs. GitHub can provide source, events and
  commit Checks without running the workflow itself.
• Use existing GitHub workflows with Openship runners — workflows in
  .github/workflows/ keep GitHub's orchestration, secrets, environments and Checks.
  Register official runners on Openship destinations and target their self-hosted
  labels. Jobs targeting GitHub-hosted labels still run on GitHub; importing a
  workflow does not silently change its execution platform.
• One workflow editor — import multiple workflow files from a repository or
  create a standalone workflow. Topology, list and YAML views share the same draft.
  Connected job and step nodes, inline step editing, per-file trigger rules, branch
  controls and repository-change review keep setup in one flow. Repository sync
  can apply updates automatically or wait for confirmation.
• Reusable workflows and advanced jobs — local and authorized remote reusable
  workflows support nested calls, typed inputs, secret forwarding and outputs.
  Dependencies, matrices, expressions and job permissions use the pinned execution
  engine rather than a second shell-only workflow implementation. Unsupported
  constructs return explicit errors instead of being silently skipped.
• Choose runners by verified capabilities — destinations report operating
  system, architecture and available tools. Linux runners support container images
  and explicit QEMU setup for supported cross-architecture execution; macOS runners
  use native tools. Runner labels and job images are separate settings. Create a
  runner from the shared server picker without leaving workflow setup.
• Review access before execution — workflow access can be limited to your
  account or selected repository users, with approval required for each attempt.
  Approvals bind the actor, commit, attempt and destinations. Fork code is blocked
  by default; explicitly approved fork execution uses disposable Cloud runners
  without privileged secrets or write credentials. Work never falls back to an
  unselected control-plane host.
• Follow runs without losing your place — expandable jobs and steps sit beside
  masked logs, with a topology view and a separate approvals tab. Waiting work has
  visible progress; selection and log position survive refreshes. Independent runs
  stream logs in Openship. GitHub-coordinated runs link to live GitHub logs and
  import completed logs.
• Artifacts, caches and OIDC — independent workflows support artifact/cache
  actions through scoped storage access and configured backup destinations. Jobs
  with id-token: write can request short-lived Openship OIDC tokens from an HTTPS
  instance. Identity providers must explicitly trust the Openship issuer; these
  are not GitHub-issued tokens. Signing keys travel with instance moves.
• Know the boundaries — independent execution does not implement GitHub
  protected environments or attestations. Windows runners and GitHub Enterprise
  Server are not supported. A fresh independent run does not resume or replace a
  failed GitHub run. Native runners and runners with a host Docker socket execute
  trusted code with that server user's access; use disposable VMs for stronger
  separation.

Cloud Actions destinations and funding

• Reuse a server or add one — Actions can use an existing authorized Cloud
  server pool or a dedicated managed server purchased through the normal catalog.
  These use the server's existing capacity and billing.
• Temporary runners per job — prepaid Actions profiles provide Linux VMs with
  2 vCPU / 4 GiB RAM / 40 GiB disk, 4 / 8 / 80, or 8 / 16 / 160. Executable jobs
  provision a temporary VM and remove it after cleanup; queued work allocates no
  VM. Temporary runners use a separate prepaid balance covering provider compute
  and transfer charges, rather than an application's monthly server allowance.
• Funding and recovery — $5, $20, $50 and $100 top-ups use hosted checkout.
  Provider-confirmed payment funds the runner budget; duplicate receipts cannot
  grant credits twice, and background recovery continues if the browser closes.
  Setup failures retain paid credit for retry. Pricing and estimated minutes use
  the provider's current tariff, not guaranteed fixed minutes.
• Cloud operator setup — temporary-runner purchases require enabled Cloud
  billing, provider credentials and live pricing. Regular-server PAYG purchases
  remain disabled. Verify a real paid Actions top-up before enabling the purchase
  flow for customers; automated payment recovery tests and live VM execution do
  not replace that checkout test.

GitHub Checks and notifications

• Deployment Checks enabled by default — repository-backed deployments can
  publish project/environment results and individual service Checks, including
  deployment failures. Configure the selected Checks and their names or disable
  reporting from project settings and the project wizard, in self-hosted and Cloud
  installations.
• Checks setup shows actual access — workflow setup displays the connected
  GitHub account, repository and access status, with inline connect, review and
  retry actions. Independent reporting requires a GitHub App with Checks write
  access; a personal token or CLI source connection alone does not grant it.
• Add notification channels inline — create a channel using the shared
  Settings form, send a test, then select it without leaving the workflow.
  Unverified channels remain unselected until verification succeeds. Completion
  notifications cover selected outcomes with durable delivery and retry.
• One notification editor — instance defaults and project overrides use the
  same channel controls. Failed preference reads show an error and retry rather
  than editable empty defaults; account switches discard stale settings.

Desktop connections and instance moves

• Move control to a server — Settings → Instance can deploy an API-only
  instance for Desktop access or an API and dashboard for browser access. Select a
  connected or managed Cloud server, configure its address and review the move.
  Projects, users, server connections, credentials, history and settings transfer
  together while application workloads remain on their existing servers.
• Move back using the latest data — a connected Desktop can receive the
  current remote instance, including changes made on the server. Existing hosted
  instances can also move to Desktop. Both ends verify compatible versions;
  interrupted transfers retain a journal and recovery snapshot and can resume
  without activating two controllers or reverting to stale local data.
• Connect without moving data — enter an existing instance URL and sign in,
  or use a short-lived connection code from your signed-in account. Desktop
  connects to that instance with your permissions; returning to the local instance
  resumes its separate data.
• Invitations open in Desktop — team invitations offer email delivery through
  the configured mail service or a copyable, recipient-bound link. Links open
  Desktop when available, with a manual URL fallback. Recipients sign in and
  review the instance, workspace, inviter and role before accepting. Team and
  webhook settings link to the same hosted-instance setup when a public control
  plane is required.

Managed Cloud servers, builds and hosting

• Manage server access in one place — managed server tabs expose settings,
  boot logs, SSH access, temporary credentials, Runtime API token reveal/rotation
  and manually managed workloads. Outbound internet and hostname allowlists use
  revision checks and preserve unrelated ingress, routes and private networking.
• Durable build admission — explicitly submitted builds queue against their
  selected server's saved offer and available resources. Different projects can
  build concurrently when capacity allows; the same project's builds remain
  serialized. Queue position, waiting reasons and upgrade actions are visible.
  Image-only deployments do not reserve a source-build slot.
• Saved plan allowances — new Hobby, Starter, Pro and Scale offers enforce
  project/app, running-service and build-admission ceilings. Existing purchases
  retain their saved terms. Physical CPU, free memory and host headroom can admit
  fewer builds than the plan ceiling; explicit resource requests are not silently
  reduced. These Cloud quota gates do not apply to self-hosted servers.
• Recover interrupted builds safely — durable activity ownership coordinates
  builds, backups and server maintenance across controllers. Capacity is released
  after tracked commands and Docker-owned BuildKit workers are confirmed stopped.
  Crash recovery settles interrupted deployment state before acknowledging its
  execution, preserves live releases and retries failed recovery writes.
• Static sites default to Cloud Pages — build on the selected managed server
  and publish the static output without retaining an application container. Choose
  Managed server hosting when an nginx container is preferred. Each release saves
  its hosting choice for rollback; failed publication preserves the previous site.
  Backend applications keep their server runtime even when static assets exist.
• More reliable application startup — generated Node images respect declared
  Node requirements and explicit image pins. Managed public Node listeners can
  adapt loopback bindings without exposing private listeners. Cloud verifies
  startup before reporting container deployments ready and surfaces crash details.
• Consistent package managers — generated npm, pnpm, Yarn and Bun builds honor
  explicit versions, supported lockfiles and monorepo parent settings, then verify
  the executable actually used. Private catalog services retain private access;
  public services use their selected domains. MinIO installation and required
  catalog setup are more reliable.

Deployment, routing and monitoring fixes

• Choose another port explicitly — when a host port is occupied, deployment
  review can suggest a free alternative and let you confirm it. Existing ports do
  not change silently. Bare redeployments recognize their own previous release,
  and private service port access binds to localhost.
• Keep routing state consistent — route repairs update the banner and route
  cards together, retain repair logs across refreshes and reconnect interrupted
  streams. Proxy overrides validate target capabilities before saving and preserve
  existing configuration when unsupported.
• Verify Cloud HTTPS at the serving edge — custom-domain checks validate the
  publicly served certificate, hostname and chain rather than relying only on
  provider metadata. Scheduled checks use bounded work and failure backoff;
  unavailable observations stay unknown instead of becoming successful results.
• Distinguish connection loss from request failures — an API request error no
  longer marks unrelated services offline. Monitoring retains meaningful last
  observations, reconnects dropped streams and offers retry for failed reads.
  Terminals remain usable when status reads fail.
• Deployment outcomes in Monitoring — projects show completed outcomes and
  failed deployments alongside application monitoring. Project cards, grids and
  backup history use more consistent spacing and responsive layouts.
• Build and runtime correctness — preserve Dockerfile startup defaults,
  native service source precedence, case-sensitive manifest names and monorepo
  Docker build-context metadata. Compose projects keep service detection on
  redeploy. Exec cancellation reliably reaps watchdog timers, including BusyBox
  hosts. Cloud cleanup follows the saved keep-resources policy. Shared storage
  removal keeps Longhorn's bounded native retry for an uninstall startup cache
  race and waits for confirmed completion before cleanup.

Diagnostics, CLI, SDK and webmail

• Structured error reporting — API boundaries, authorization failures,
  deployments, jobs, streams and dashboard errors share a classified, redacted
  event format with request references and bounded asynchronous delivery. Cloud
  stores sanitized events in its own database. Automatic collection and upload
  remain disabled for Desktop, self-hosted installations, native workers and CLI,
  including Desktop connected to Cloud; operational errors still have local logs.
• Broader automation coverage — native and remote SDK operations cover Actions,
  instance connections, managed server controls, migrations, mail and terminals.
  The CLI shares platform contracts, expands Cloud and remote operations, accepts
  /api paths and positional environment pairs, and guides users to login on
  authorization failures. Actions are available through openship api; this
  release does not introduce a dedicated openship actions command group.
• Updated documentation — Actions setup, independent versus GitHub execution,
  runner access, Cloud funding, instance moves and API/SDK/CLI/MCP references cover
  the new flows, with live execution verification records.
• Webmail improvements — editable email signatures apply in the composer;
  replies include the original message body. Sign-in recovery and managed
  deployments are fixed. Cloud shows mail availability before loading unsupported
  server controls; Desktop and self-hosted mail remain available.
• Additional compatibility fixes — preserve cookie encoding in dashboard
  server requests, complete partially applied instance-controller migrations,
  filter invalid custom app templates, and add Farm.js configuration support and
  its square icon. Whole-instance recovery rebinds the imported local administrator
  atomically, preventing project reads from failing after a database wipe.
• Release verification — required gates cover real Linux and macOS Actions
  execution, instance moves, Docker deployment/rollback, scaling and shared
  storage, HTTPS, database upgrades and installed SDK packages. Failed release
  work can resume with verified successful checks and notarization checkpoints.

Updating

Desktop 0.8.2 users can use the built-in updater. Desktop users still on 0.8.0
or 0.8.1 must download the 0.9.0 installer
and install it manually once. Quit Openship and replace the application; keep
application data to preserve projects, servers and settings. The server/CLI
update path does not require this desktop recovery step. Update the API and
dashboard together; instance moves require compatible versions at both ends.