oblien/openship v0.9.2

Openship v0.9.2

on GitHub

This patch adds worker and scheduler execution, personal appearance customization,
and managed Cloudflare Tunnel setup for self-hosted servers. Cloud spaces, reusable
build caches, more catalog apps and safer storage cleanup improve everyday
operations. These notes cover all merged changes since 0.9.1.

Workers and schedulers

• Run roles beside your web app — declare workers and schedulers in
  openship.json or the project API. Single-app Docker deployments start separate
  containers from the app image, with shared environment, volumes and connected
  networks, their own commands and shutdown settings, and no published ports.
  Roles follow pause, resume, restart, rollback and project deletion.
• Hand over singletons safely — scheduler renames, command changes, name swaps
  and conversions into workers stop and retain outgoing singletons before starting
  potentially conflicting replacements. Failed deployments restore them only after
  those replacements are confirmed removed. Failed retirement of an old role is
  surfaced in the deployment warning with its container identity.
• Require a verified startup — every replica needs exactly one stable result
  for its container ID before optional exec health checks run. Missing inspections,
  duplicate results and processes that already exited successfully fail startup.
  Both project-defined and image-inherited PORT values are removed from roles.
• Make role configuration explicit — move and copy refuse active, unfinished
  or preserved-cancelled role workloads even after saved roles are cleared.
  Preset-only when and unless keys in declared roles produce warnings rather
  than silently appearing to control execution. Automatic framework role selection
  and cross-server role migration are not included.
• Improve framework shutdown defaults — Rails presets have measured stop
  settings, and Laravel's scheduler preset uses SIGTERM with a 10-second grace
  period while queue and Horizon workers retain 90 seconds. Customize these bounds
  for long-running tasks; they do not guarantee task completion or exactly-once
  scheduling. Laravel web-role cache warming is available as an opt-in setting.

Appearance and dashboard

• Customize your own appearance — Settings → General → Customize previews
  color tokens and typography live, with explicit Save, Discard and Reset.
  Import themes from JSON, a file or an HTTPS URL; export themes and libraries,
  including supported WOFF2 fonts. Preferences belong to the signed-in user and
  stay isolated across accounts and instances. API, SDK, CLI and MCP operations
  use the same theme format.
• Keep operational tools together — project monitoring and logs share one
  navigation entry with their own views. Backups moves under Infrastructure.
  Project sidebars show assigned domains, migration retries retain destination
  choices, and migrated service deployments use the correct icons.
• Reduce false outage alerts — the health watcher confirms repeated bounded
  Docker probe failures before announcing a server outage. Late probe replies
  cannot falsely announce recovery. Self-hosted administrators can clear resolved
  monitoring history with confirmation while retaining open incidents.
• Improve navigation and terminal reliability — GitHub discovery no longer
  blocks dashboard pages, selection controls use consistent states, and leaving a
  server terminal during WebGL loading cancels setup and disposes the terminal.
  Instance connection and move actions have clearer setup and recovery guidance.

Cloudflare Tunnel and domains

• Manage self-hosted ingress from Openship — Server → Security can connect or
  create a remotely managed named Cloudflare Tunnel using saved credentials,
  configure proxied DNS and optionally apply an existing reusable Access policy.
  Install a pinned connector on a supported Linux server or use its existing
  connector. Managed Openship Cloud routing retains its existing path.
• Enroll domains with recoverable setup — explicitly enable automatic tunnel
  enrollment for new custom domains or connect existing domains individually.
  Setup records Access, tunnel and DNS progress, supports retry after interrupted
  requests, and removes only owned resources. External edits remain visible for
  review instead of being overwritten. Exact hostnames and www companions are
  supported; wildcard auto-enrollment is not.
• Choose primary and www behavior — the deployment wizard defaults a newly
  included companion hostname to a 301 redirect to the entered primary. Choose
  bare primary, www primary or Serve both on Cloud and self-hosted destinations.
  Redirect rows show their target instead of duplicate runtime inputs.
• Keep domain operations consistent — service aliases on the same port are
  preserved, domains added through the CLI receive routing, and Cloud routing
  retries recover missing Pages through the owning Cloud connection.
• Honor trusted proxies on containerized edges — operator-declared proxy IPs
  reach the edge without rebuilding its image. Invalid addresses and CIDR prefixes
  are discarded. Failed configuration updates restore the previous shared trust
  include, and an incomplete rollback cannot activate a partial configuration.

Cloud spaces, billing and connections

• See managed capacity as Cloud spaces — a shared picker, Overview and
  Activity views show projects, purchased capacity and measured usage, with clear
  retry states for unavailable readings. Existing allocations and subscriptions
  keep their identity; connected self-hosted server tools remain available.
• Use the owning Cloud account consistently — connected Desktop and
  self-hosted installations create Cloud projects through Cloud's API. Server,
  project and deployment operations enforce their organization and provider
  namespace. Cloud consent shows the actual account and organization and lets you
  switch either before explicitly authorizing the connection.
• Continue purchases without repeating plan selection — pricing links carry
  the chosen plan into the signed-in app's checkout flow. Pending unpaid payments
  can be cancelled when supported by the provider so another plan can be selected;
  retries retain the original payment identity. Server cancellation is easier to
  find and repeated requests cannot create duplicate operations.
• Configure Actions on existing spaces — Cloud's Add runner flow opens the
  capability form directly with the space picker. Local Actions lists remain
  available when Cloud discovery fails, and official runner containers support
  non-root SSH supervisors. Temporary runner profiles retain their separate
  funding flow.
• Keep instance handoff with its source — control-plane provisioning on a
  linked managed destination stays owned by the source controller until the move
  transfers the instance, including resumed API-only and dashboard installations.

Build performance and resource control

• Keep unconfigured resources uncapped — omitted build and service CPU/RAM
  limits no longer become sampled capacity caps or catalog sizing recommendations.
  Containers share the selected server's capacity unless limits are explicitly
  configured. Cloud plans and VM capacity still apply. Existing saved limits are
  preserved; select Full capacity to remove an older unwanted limit.
• Allow concurrent Cloud submissions — different projects can submit builds
  while a sibling build is active. Unspecified resource dimensions remain shared;
  explicit limits, saved plan concurrency and exclusive maintenance protection
  remain enforced.
• Reuse bounded project build caches — compatible builds retain project-owned
  BuildKit state and supported package/compiler caches while temporary workers
  are removed. Idle cache collection uses retention targets and storage-pressure
  checks, preserving active workers, release images and application data.
• Optionally warm new Cloud spaces — operators can select a provider software
  disk with public build-image layers for new spaces. Matching images are pinned
  against their current upstream digest; unavailable or outdated packs fall back
  to registry resolution. Existing spaces are not reattached by an API redeploy.
• Show what image preparation is doing — registry pulls stream progress,
  preparation heartbeats and elapsed time into deployment logs. Build cleanup
  waits for tracked Docker commands to acknowledge completion, and static export
  publication normalizes public file permissions.

Catalog, GPUs and shared databases

• Add document, dashboard and media apps — install Paperless-ngx, Wiki.js,
  Homepage, Immich and Jellyfin using pinned published images, persistent storage
  and protected initial setup. Homepage does not require a Docker socket.
• Run self-hosted AI apps — Ollama offers CPU or one NVIDIA GPU, and Open WebUI
  connects to an existing backend with protected chat access. These templates use
  connected self-hosted destinations, not managed Cloud capacity. vLLM remains a
  disabled preview pending hardware verification.
• Deploy NVIDIA GPU services — Compose import, SDK/CLI sync and adoption share
  validated GPU selection and Docker device requests. Server detection and picker
  hints help choose a compatible destination. Unsupported or conflicting requests
  fail before image acquisition or service replacement.
• Skip unnecessary WordPress and Odoo builds — new catalog installs pull the
  official images and mount setup helpers through the normal deployment engine.
  Existing installations retain their saved recipes; reviewed catalog repair can
  update the application service while preserving database siblings, credentials
  and data.
• Share native databases explicitly — Use in a project can connect ready
  native PostgreSQL or Redis databases to authorized projects in the same cluster.
  Saved grants and private network rules are checked together; ownership, backups
  and database management stay with the source project.

Storage, deletion and migration safety

• Separate fresh Cloud app data — new logical volume names use immutable
  project IDs so reinstalling a deleted slug cannot adopt another project's data.
  Owned legacy mounts and explicitly imported volume identities remain intact.
• Recover failed deletion clearly — failed first installs offer the existing
  explicit data-removal option, including owned volumes with no container. Data
  retention stays the default. Cleanup failures remain retryable operations
  instead of making a partly deleted project appear Live again.
• Preserve resources belonging to other projects — teardown can retain stale
  Cloud route and network references whose foreign ownership is confirmed.
  Unreadable or ambiguous ownership still blocks cleanup, and owned networks are
  removed by immutable identity rather than a potentially reused name.
• Avoid ephemeral host-port collisions — Docker allocation checks the target
  kernel's ephemeral range for both saved preferred ports and fresh candidates.
  Unsafe legacy allocations move to a safe port during deployment; if no safe
  candidate exists, allocation fails before reserving a replacement.

Mail, security and localization

• Persist webmail backend connectivity — webmail deployed on its mail server
  saves the host-gateway mapping through normal service settings and deployment
  snapshots while retaining the certificate hostname for TLS. Sign-in connection
  attempts have bounded timeouts rather than hanging indefinitely.
• Connect existing mailboxes from Cloud — the Emails screen installs the
  standard webmail client for existing IMAP/SMTP servers. It does not provision or
  administer a self-hosted mail server in Cloud; managed email remains Coming soon.
• Repair containerized mail operations — boot restores maildir ownership,
  backups and restores use the actual host-mounted mail path, and fail2ban uses
  valid nftables syntax and explicit private PostgreSQL sidecar credentials.
  Database and unban failures no longer report success.
• Resize your inbox and reading pane — drag the divider or use its keyboard
  controls. Desktop widths are remembered separately from the mobile layout.
• Prevent dashboard clickjacking — dashboard pages, authentication routes and
  redirects deny framing through CSP and X-Frame-Options. Customer application
  routing and headers are unchanged.
• Expand translated guidance and documentation — supported dashboard locales
  include preferences, transfer, jobs, issues, pricing, diagnostics and audit
  descriptions. The website adds a blog and broader feature discovery, alongside
  updated catalog, runtime-role, Cloud, API, SDK, CLI and MCP documentation.

Update the API as well as Desktop/dashboard clients before using the new settings,
managed tunnel operations or catalog recipes that require 0.9.2. The included
database migrations run through normal API startup.