Openship Files

Scale applications, PostgreSQL and Redis across your own servers, connect those servers through private networking, and share files between application instances. This release also adds the Node.js SDK, expands MCP automation, refreshes the dashboard and desktop experience, and brings the deployment, environment, routing, backup, mail and security fixes accumulated since 0.7.2.

Server clusters and private networking

• Connect servers across providers — register and verify an existing private network or prepare an Openship-managed WireGuard network across your servers. Provider network groups retain their provider and network details; managed networking also supports custom infrastructure (#899, [#900]).
• Networks and compute clusters have separate responsibilities — the Networking tab owns addresses, connectivity and network operations. The Clusters tab groups selected servers from a private network and manages the runtime used by their projects.
• Choose which servers can reach each other — edit connections in the network topology, allow traffic in both directions or one direction, or remove a connection. Openship enforces the private-access policy on supported hosts and shows the provider firewall rules to apply before setup. Cluster setup checks that its selected servers have the bidirectional connectivity it requires.
• Test the network from the topology — on-demand checks verify allowed paths and confirm that denied directions reject new connections. Results include TCP/UDP reachability, MTU, round-trip latency, loss and jitter; a selected pair can run a bounded throughput test. Saved results remain available for diagnosis.
• Prepare, review, retry and clean up network changes — missing prerequisites can be installed automatically, address allocation and firewall requirements are reviewed before apply, and reconnectable progress includes per-server steps and errors. Interrupted work exposes explicit retry or rollback. Failed members can be removed from setup, and removal reverts owned network changes.
• Prepare servers for application scaling — self-hosted and desktop controllers install k3s under the hood, join the selected SSH servers, and verify node readiness, pod traffic, service routing and internal DNS. Saved progress supports retry after failure or interruption; runtime removal checks dependent workloads and owned infrastructure first (#912).

Application scaling

• Run an application or worker across your servers — select a prepared cluster, publish the application's image to a shared registry, and deploy through the normal project flow. Set 1–100 replicas; subsequent replica changes reuse the active immutable image without rebuilding. Openship Edge routes public requests to the application, and the topology shows observed instances, placement and readiness.
• Update, roll back and recover running applications — cluster deployments retain image history for rollback, and failed or cancelled candidate releases preserve the active release. Kubernetes replaces failed instances within the prepared cluster and routes to surviving ready instances after detecting an unavailable worker. Revision checks reject stale changes to a running project.
• Mount shared files in application instances — project-owned shared volumes can be attached at configured paths, including read-only mounts. Instances on different servers can read and write the same files; existing node-local mounts require a separate data migration.

Databases and shared storage

• Choose standalone or clustered PostgreSQL — managed databases have their own resources, progress, credentials and lifecycle. PostgreSQL clusters provide replicas, primary recovery, and private read/write and read-only endpoints. The database controller owns replication and failover independently of the application's replica count.
• Run Redis standalone or as a cluster — Redis clusters distribute data across shards with replicas. Grow or reduce the shard count after reviewing the change and taking a verified recent backup. Redis Cluster requires a cluster-aware client; resizing checks real cluster health and slot ownership.
• Back up and recover PostgreSQL and Redis — configure an eligible S3 destination for manual, hourly or daily backups. Restore a verified archive into a separate database, inspect it, then explicitly replace the application's saved connection and redeploy. Redis archives preserve values and expiry and are consistent per shard, rather than one transaction across all shards.
• Import existing databases and stage PostgreSQL upgrades — import eligible Docker PostgreSQL or Redis backups while the original application remains on Docker. PostgreSQL 17-to-18 upgrades create a separate logical copy for checking before connection replacement. Source data remains available; changes after the captured recovery point need a fresh capture before final cutover.
• Share files with independent disk copies — enable shared storage on at least two independent servers, choose two or three copies, and create project-owned volumes. Inspect attachment and copy health, grow a mounted volume, and rebuild a lost disk copy.
• Recover files from outside the cluster — take manual or scheduled external backups and restore them into a new shared volume. Archives remain discoverable after deleting the original volume or removing empty shared storage; archive deletion is an explicit separate action.
• Keep data when removing a database — removal can retain its data for later recovery or explicitly delete it. Application, volume, storage and runtime cleanup enforce dependencies and ownership, so an unfinished cleanup or retained database cannot silently lose the infrastructure it still needs.

SDK, CLI and MCP

• A Node.js SDK alongside the CLI — the openship package now provides OpenshipClient through openship/client for remote installations and createShip through openship/native for an embedded engine without a separate API server. Both use shared platform operations, validation and authorization. Native instances have explicit start/close lifecycles and verified workspace scopes; ESM and CommonJS are supported on Node.js 22 and newer (#887).
• MCP covers more of the operational lifecycle — networking, cluster setup, replica scaling, managed databases, shared files, backup/restore, migration, routing and diagnostics have documented tools and ordered workflow prompts. Discovery respects workspace permissions and instance mode; required arguments and DELETE bodies survive dispatch, and path arguments cannot redirect a call to another route. Generated API, CLI and MCP references describe the available operations and explicitly excluded HTTP-only routes (#953).
• CLI workflows use the shared SDK — native mode and remote clients share deployment and source handling, and Jobs now has commands for its existing management and execution flows. Re-login preserves custom context endpoints, folder uploads require explicit opt-in, project display names can be changed safely, and failed component installation returns a failure to the caller.

Deployments and builds

• Run release commands before activation — configure releaseCommands in Build settings, openship.json or the project API/SDK. Commands run in order after building, using the candidate release's environment, with streamed logs and a ten-minute budget per command. Failure, timeout or cancellation stops activation. Single-app Docker and Bare deployments are supported; unsupported deployment types reject configured commands. Rollbacks skip them, and rolling back application code does not undo database changes (#592).
• Completion and elapsed time survive retries and refresh — workers retry a failed database completion acknowledgement without repeating deployment work. Cancellation records its outcome and duration atomically; late worker results cannot replace them. Both build views use the same persisted timing, including queued starts, rejected retries and terminal events (#940).
• Rollback retention has a predictable limit — Project → Advanced → Rollback history defaults to five past deployments, with active and pinned deployments kept in addition. Cleanup runs after deployment and retention changes, retries failed removals, and preserves artifacts still referenced by another retained release. Older history remains browsable with pagination and accurate snapshot labels.
• More reliable source builds — recursive Git submodules are fetched for build checkouts; Ruby builds respect declared versions and preserve Rails storage; PHP builds include EXIF and package assets needed by frontend builds. JavaScript PORT assignments are detected, invalid empty monorepo creation is rejected, and build-time service-DNS failures receive an actionable explanation.
• Deployment errors reach the UI — rejected submissions show the API's specific validation or configuration error. Build streams reconnect without replaying output, and successful deployments can show live service logs. Preview variable sets cannot be deployed onto a production project's runtime.

Environment and Compose

• Saved service variables stay visible — the Environment tab reads effective values from Openship, including Compose values, shared project variables and explicit service overrides, with their sources. It remains usable when the server is offline. Saves update only edited rows, preserve untouched secrets, reject conflicting edits and remove an override by restoring inheritance where available (#926).
• Compose updates apply without routine approval gates — repository changes merge automatically while explicit operator overrides remain. Saved environment values survive omitted source keys, unresolved expressions and legacy review resolution. Interpolation uses current configured values instead of stale scan results; legacy pending reviews reconcile on redeploy (#893, [#916]).
• Recover and apply environment changes deliberately — older or migrated services can recover missing variables from their running container for review and saving, without overwriting saved values. Apply compares against the running service and recreates supported Docker services from their existing image, retaining ports, networks, mounts and resource limits. Failed startup restores the previous container; unavailable comparisons remain unknown, and unsupported runtimes direct the operator to redeploy.
• Environment download and secret protection — Download .env exports the listed values, including saved secrets, using quoting that round-trips through Upload .env. Inline service environment, build arguments and their saved deployment/Compose snapshots are now encrypted at rest; API presentation masks protected values and preserves them on round trips (#844).

Migration and portability

• Compose migration includes the domain handoff — discovery reports existing proxies and matches Traefik routes through private container addresses as well as published ports. The wizard saves service environment and selected routes, prepares Edge during migration, and requests confirmation before taking over an existing proxy. Selected sites attach to their migrated services, existing certificates are reused, and unresolved routing prevents automatic source container removal (#905, [#908]).
• Reuse a service across projects — shared service connections retain the service's owner, data and connection settings instead of duplicating it. Existing Docker private links require separate migration when moving an application to a cluster.
• Export a project's configuration, environment and credentials — project settings download a portable plaintext file without a passphrase. The export identifies its server and Cloud dependencies; import previews the contents and requires explicit target mappings. Runtime data stays on its original server, and Cloud projects require the same Openship Cloud account. Imported credentials are encrypted with the destination instance's key. Configuration transfer does not copy runtime volumes or perform a whole-instance server cutover.

Domains and certificates

• Wildcard HTTPS with automatic DNS or manual TXT verification — project and service domains such as *.example.com now open inline certificate setup. Connected DNS providers automate verification; manual TXT orders retain their progress across reconnects and controller restarts. API, SDK and MCP share the same start, status, check and cancel operations. Existing certificates survive failed attempts, and HTTPS is reported ready only after its route is active. Manual certificates include renewal guidance in all nine dashboard languages (#954).

• Manage multiple wildcard domains — configure wildcard domains in Settings and choose the domain to use during project setup (#819).

• Routing retries reconcile saved and live state — Retry routing checks Edge, reapplies project routes and synchronizes domains, with inline progress logs and refreshed results. Live ownership checks recover stale hostname/host-port reservations left by deleted or recreated projects. Repairs preserve complete routes and canonical endpoints when aliases are removed (#915, [#922], [#925]).

• Pending states explain what happens next — domain details distinguish verification in progress, scheduled retry and failure, show the reason and next retry time, and offer a manual retry. Durable backoff prevents overlapping background sweeps from repeatedly retrying the same domain. An SSH observation failure no longer clears a working certificate or becomes a claim that HTTPS is absent (#911, [#922]).
• Imported certificates and container routes recover correctly — certificate lookup follows managed lineages and avoids collisions after import; recovery excludes ACME challenge ports from application upstreams. Static sites inside containers route through their owning service, and Edge serves an Openship error page for unavailable upstreams (#879, [#913]).

Backups and restore

• Back up now from the project, service or volume panel — service shortcuts reuse an applicable policy and run only the selected service. Project policies skip stateless services and admit their eligible runs together. Progress shows saved phases, elapsed time and transferred bytes, reconnects across workers, and updates recent history even after the progress view is dismissed.
• Optional incremental backups — policies can reuse verified unchanged blocks, with a complete block index for each restore point. Retention preserves blocks still referenced by another snapshot, and storage totals count shared objects once. Full backups remain the default. Captures still scan the whole source and transfer through the Openship backup worker.
• Retention and destinations remain consistent — pruning runs after successful capture and through the scheduled sweep, preserving protected copies and backups used by active restores. Existing runs retain their original destination when a policy changes, and failed cleanup remains retryable without invalidating a successful backup. SFTP failures close streams and clean partial uploads instead of leaving the worker stuck (#817).
• Restore validates before replacing data — preparation and confirmed apply share source/target checks, integrity verification and exclusive access to the project or mail server. Runtime/stop failures abort before destructive writes; partial-write failures are reported and do not automatically restart a service on incomplete volume data. Redis/Valkey restore validates persistence settings, and PostgreSQL restore uses a transaction for each supported artifact. Release tests now exercise backup, incremental reuse, retention and restore with real Docker volumes and databases (#892, [#946]).

GitHub and access

• Cloud GitHub connections finish in the dashboard — installation completion refreshes repository access and the connection state instead of leaving the page loading after GitHub has finished. Device sign-in keeps its code and instructions visible until completion; transient and rate-limit failures no longer discard durable credentials (#920, [#951]).
• Repository selection stays in sync — branches load on demand while keeping selection and keyboard focus, and changing the branch rescans deployment configuration. Partially successful push-webhook dispatches retry failed targets without redeploying targets that already completed (#847, [#870]).
• Sign-in and invitations respect the configured flow — clients can discover enabled login providers, and signed-out invitees can reach account creation and complete acceptance without the dashboard's prior navigation race.

Dashboard and desktop

• Shared icons and more consistent layouts — dashboard and desktop use a theme-aware icon catalog with bundled local assets. Service headers, tabs, environment controls, volume forms, source settings and log controls have consistent spacing and typography; mobile navigation and crowded rows are improved (#942, [#946]).
• Topology stays inside the project — the graph has an optional expanded view, improved loading placeholders and compact service nodes. Clicking a node opens its details directly; long runtime identifiers truncate with copy actions rather than widening the panel.
• Deployment pages put actions and logs first — Open site and Open project remain prominent, multiple exposed domains can be selected, and preparation, service status and single-app steps share clearer progress indicators. Logs have bounded layout, search and copy controls; history filters survive returning from a deployment.
• Backup pages show retained data and real run state — global and destination views share paginated history, restore actions and usage information. Successful retained copies, active attempts and physical storage totals are distinguished; history remains available after policy changes.
• Desktop startup follows the application theme — a redesigned loading screen uses shared colors, clearer progress and service startup states (#952).

Monitoring and runtime reliability

• Monitoring recovers after connection interruptions — desktop connectivity loss is distinguished from a confirmed remote runtime failure, with recheck and reconnection handling. Overlapping status requests no longer stop polling or replace newer results, and issue feeds remain available when a host adapter cannot start. Services show a checking state while runtime status is unknown (#927, [#949], [#951]).
• Traffic views use the same time series — overview and monitoring render timestamped request buckets with clear time ranges, area/column views and loading skeletons. Analytics failures stay within the affected view instead of appearing as empty traffic or replacing fresh data with stale responses.
• Long-running resources are bounded and released — container log retention is bounded for newly created managed containers, session caches preserve active work at capacity, and closed log, terminal and IMAP streams release their subscriptions. Busy builds retain their SSH transport; abandoned terminal handshakes release their slots and resumed shells remain bound to the authorized target (#950, [#951]).
• Server administration reports actionable failures — macOS hosts expose system statistics, server responses match shared diagnostics contracts, and deletion refuses hosts with active deployments. SSH group refresh preserves active sessions after Docker installation.

Cloud and API

• Cloud billing follows the selected organization — plans, checkout, credit top-ups and renewal management use Oblien namespace entitlements. Purchased limits survive catalog changes, deployment/recovery checks enforce available capacity, and checkout completion verifies payment delivery rather than trusting the return URL. Billing portals remain scoped to the organization (#910).
• Standalone APIs limit unauthenticated floods — a separate per-IP guard runs before authentication without consuming the route's own limit. Cloud mode or explicit OPENSHIP_TRUST_EDGE=true delegates that outer ceiling to the upstream proxy while preserving per-route limits (#123).

Mail

• Check and renew the certificates mail clients actually use — mail settings show expiry and the certificates served by SMTP and IMAP, with actions to check and renew them. Successful renewal reloads Postfix and Dovecot and verifies the served certificates. Automatic renewal uses the shared scheduler; expiry, renewal failures and stale served certificates appear in Health and Monitoring. Scheduled renewal requires the Openship controller to remain running.
• Webmail refreshes without duplicate subscriptions — inbox updates use a single owned SSE/IMAP IDLE connection with cleanup on disconnect. Replies fill recipients and subject correctly, Trash uses IMAP deletion, and mobile composer, accessibility and browser-cache failures are corrected (#897, [#904], [#921], [#950]).
• Remote-content blocking also covers CSS — disabling remote images prevents CSS imports and URL-based fetches from leaking a read receipt (#220).
• Mail setup, delivery and alerts are more reliable — setup distinguishes an unverified public SMTP probe from a stopped server; database port selection handles conflicts; mounted certificates and Amavis state recover on restart. Relay TLS and SES MAIL FROM checks are corrected, delivery health evaluates the full queue, and captured messages remain until notification delivery is durably queued. Job and backup notifications include their relevant target, outcome and log details (#834, [#865], [#867], [#945], [#951]).

Release checks

• Continue an unpublished release with updated code — reuse successful whole checks only when their source and workflow inputs match, and rerun failed or affected checks. Artifact reuse verifies the original run and immutable artifact identity; concurrent tag changes and earlier publishing attempts prevent unsafe continuation.
• Real application, database and shared-storage acceptance journeys — release checks exercise MCP dispatch, image publication, deployment, public routing, scaling, updates, rollback, worker recovery and project cleanup. Separate database tests verify real queries, replica/shard changes, backups, restores, imports and upgraded copies. Shared-storage tests use independent Linux VMs for SSH installation, cross-server writes, volume growth, disk-copy rebuilding and external backup recovery. These heavier journeys run in the release gate or on demand.

Upgrade notes

• Scaling scope in this release — cluster management is available from self-hosted and desktop controllers. Application scaling supports single apps and workers with project-owned shared files. Compose application scaling, CPU/traffic-driven autoscaling, automatic server provisioning and live cluster membership changes are not included.
• Keep the database and encryption key together — this release includes database migrations and converts legacy plaintext service configuration when the engine starts. Back up the database and retain the instance encryption key (BETTER_AUTH_SECRET for API installations) before upgrading. Downgrading to a version before this protection requires its matching database backup. Use Data Transfer with secrets included when moving configuration between instances with different keys.

Full comparison: v0.7.2…v0.8.0