Openship Files

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.