Openship Deploy

Deploy and operate OpenShip

Prefer the CLI and an existing self-hosted instance. Use a cloud or desktop workflow when the user requests it. Keep application deployments separate from installing or upgrading the OpenShip control plane.

Choose the instance and command

• Check openship --version and openship context list. Select the intended self-hosted context before a remote operation. Never assume the active context points to the user's server.
• Use native commands with the global --json flag. Read CLI access for context and authentication details. Do not print stored tokens.
• Check the installed command's --help. Use openship api for routes without a working command, after checking the matching implementation. In v0.7.2, service exec and server ssh are stubs despite appearing in help. A successful help command does not prove an operation works.
• upstream.json records the bundled release, exact source URLs, and hashes. If the installed CLI or server differs, verify the relevant source at that version before relying on a flag or API contract.

Deploy an application

1. Inspect the repository, existing project link, build entry point, service topology, persistent volumes, and current domain ownership. Use projects and services for commands.
2. Use the companion openship-config skill to author a small openship.json. When only this ZIP is installed, use the official config guide. Keep repeatable build and routing choices in the repository. Keep actual credentials in the instance's environment settings.
3. Run openship --json config validate, then use deployment commands for the appropriate repository or folder deploy. A valid file does not prove its image builds or that the destination has sufficient capacity.
4. Check deployment completion, the active deployment, service health, logs, and the public URL. Report the deployed revision and any checks still pending. Use edge and monitoring for diagnosis.

Read only the guide needed for the operation:

• Self-hosted GitHub App: repository authorization and automatic deployment.
• Domains: ownership, DNS, ports, and HTTPS. Reconcile existing ownership before moving a hostname.
• Persistent storage: volumes and data that must survive redeployment.

Maintain the self-hosted instance

Use self-host infrastructure for servers and backups, and running OpenShip for lifecycle commands. Inspect how the instance was installed and whether it has a custom updater before selecting an upgrade command.

• Updates: CLI and server lifecycle.
• Backups and restore: protection and recovery of application data.
• Instance migration: control-plane export and import.

Use the user's existing authorization for the requested operation. Preparing a deployment is not authorization to replace a running instance or restore over its data.