This release improves Cloud monitoring and build-cache reliability, adds deployment automation and isolated pull-request previews, and makes workers and schedulers easier to configure, observe and recover. These notes cover all merged changes since 0.9.2.
Deployment automation and previews
- Move command variables into Environment — review literal environment assignments in install, build and start commands, then migrate them into encrypted project or service settings. Conflicts and concurrent edits stop the migration before partial changes are saved. Import and saved settings share the same parser and guidance.
- Prepare framework output automatically — Next.js standalone monorepos and Nuxt builds retain their required workspace dependencies, public/static assets and selected Node or Bun runtime. Managed direct-server defaults start from the configured app directory; explicit custom commands retain their working directory.
- Review older manual cache mounts — detect duplicate package/framework cache mounts and offer configuration migration only after a successful build proves managed cache support for those paths. Existing volume data is retained. Build logs report observed cache reuse and build-time comparisons.
- Catch setup problems earlier — pre-install checks identify missing app roots and environment examples; command-variable, standalone startup and duplicate-mount guidance explains what needs attention without exposing variable values.
- Opt into GitHub pull-request previews — same-repository, non-draft pull requests can deploy their exact commit into a separate preview environment with preview-only variables, isolated volumes and per-service URLs. Production variables are not copied. Forks and unsafe shared-storage configurations are excluded.
- Recover preview lifecycle operations — durable coordination handles repeated webhooks, controller restarts and retryable close/merge cleanup. Optional GitHub comments update one existing comment, alongside the existing deployment Checks. Whole-instance transfers preserve preview ownership; individual project imports clear preview automation that cannot safely transfer.
- Use automation from the SDK — configure and list previews, inspect or migrate manual cache mounts, and move command variables through the shared validated project operations.
Workers, schedulers and rollback
- Configure roles without rebuilding the web app — Apps & Services → Configure roles can add or change workers and singleton schedulers on active single-app self-hosted Docker deployments. The normal deployment engine reuses the verified image and frozen environment while preserving the web container and unchanged replicas. The API, SDK and CLI expose the same operation. Cloud, bare, static, cluster and multi-service targets are outside this editor's scope.
- See and inspect background processes — runtime roles appear in project service views and topology, with role/replica log selection and retry states. Health monitoring includes worker and scheduler failures instead of observing only the foreground container.
- Keep independent role suggestions — framework scans expose matching presets at the selected app root. Only presets competing for the same declared slot exclude one another; explicit roles, including an empty list, retain precedence. Suggestions do not automatically enable background processes.
- Recover interrupted role handovers — persist exact container identities and ownership before replacement, predecessor shutdown and publication. Startup and deployment reconciliation either finish a published handover or safely restore its predecessor; uncertain cleanup remains pending before conflicting work.
- Protect active and rollback images — retained role replicas keep their required image artifacts protected during configuration changes and release cleanup.
- Restore frozen Compose environment accurately — rollback preserves encrypted deployment snapshots without confusing literal redaction-like values with missing secrets. Incomplete legacy snapshots fail clearly rather than borrowing mutable current service settings.
Cloud monitoring, caches and storage
- Avoid expensive monitoring scans — Cloud hosts using fuse-overlayfs skip Docker's full storage inventory, which can exhaust daemon memory. Host totals remain measured; unavailable detailed project storage stays unknown.
- Show guest RAM usage — use verified guest counters instead of hypervisor process memory and overhead. Older guests receive a bounded, read-only memory sample; stream teardown releases the executor.
- Keep partial metrics useful — missing disk or memory fields in a live frame retain the latest measured value for that metric, with its measurement time. Purchased capacity is never substituted for measured consumption.
- Keep Cloud cache cleanup scoped — collect only owned, idle project-worker caches and stop before Docker Engine's global builder prune. Cache reuse, worker GC, existing build concurrency and user-configured resource limits are unchanged. Cloud builds require their isolated BuildKit executor instead of silently falling back to the embedded builder. Existing legacy daemon state and autonomous Docker GC remain separate host-maintenance concerns.
- Accept filesystems without fixed inode totals — unsupported or zero inode totals mean unknown availability rather than confirmed exhaustion. Real free-space and supported inode-exhaustion checks still protect deployment admission.
Domains and ingress
- Route verified custom domains on first deployment — single-app domains without a saved destination use the verified serving port through the shared route planner. Explicit endpoints and service-group destinations retain their ownership instead of selecting a sibling service.
- Avoid ephemeral secondary host ports — secondary loopback publications use the existing allocator and the target host's ephemeral-range checks.
- Handle varied Cloudflare Access applications — accounts containing launcher or other domain-less applications no longer crash managed ingress setup. Inventory and write receipts are validated while overlap and foreign-resource ownership protection remain enforced.
- Clarify edge availability — documentation explains edge failure behavior and recovery responsibilities for deployed applications.
Webmail
- Resolve exact Message-IDs for actions — thread reads, deletion, labels and flags validate exact IMAP envelope identities instead of trusting substring search matches. Literal percent sequences remain unchanged, stale UID hints are rejected, and missing or refused operations no longer report success.
- Cache application assets correctly — fingerprinted assets receive immutable caching while application HTML is revalidated.
- Serve precompressed assets — negotiate available Brotli or gzip files with appropriate content types, encoding and cache headers.
