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, and automation for CI logins and scripts that pass explicit project IDs. 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.8.0, server ssh is a stub 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 and logs for diagnosis, and build failures when the deploy goes red.

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. Domain and SSL failures covers certificates that do not issue.
• Rollback and redeploy: return to a previous version or rebuild one from scratch.
• 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.