/openship-deploy

name: openship-deploy
description: This skill should be used when the user asks to "deploy with OpenShip", "manage a self-hosted OpenShip instance", "debug an OpenShip deployment", or manage its domains, storage, backups, or upgrades through the CLI.

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](references/cli/access.mdx) for context and authentication details, and [automation](references/cli/automation.mdx) 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](references/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](references/cli/projects.mdx) 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](https://openship.io/docs/guides/openship-json). 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](references/cli/deploy.mdx) 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](references/cli/edge.mdx) and [logs](references/guides/logs-monitoring.mdx) for diagnosis, and [build failures](references/troubleshooting/deployments.mdx) when the deploy goes red.

Read only the guide needed for the operation:

• [Self-hosted GitHub App](references/guides/self-hosted-github-app.mdx): repository authorization and automatic deployment.
• [Domains](references/guides/custom-domains.mdx): ownership, DNS, ports, and HTTPS. Reconcile existing ownership before moving a hostname. [Domain and SSL failures](references/troubleshooting/domains-ssl.mdx) covers certificates that do not issue.
• [Rollback and redeploy](references/guides/rollback-redeploy.mdx): return to a previous version or rebuild one from scratch.
• [Persistent storage](references/guides/persistent-storage.mdx): volumes and data that must survive redeployment.

Maintain the self-hosted instance

Use [self-host infrastructure](references/cli/self-host.mdx) for servers and backups, and [running OpenShip](references/cli/run.mdx) for lifecycle commands. Inspect how the instance was installed and whether it has a custom updater before selecting an upgrade command.

• [Updates](references/guides/updating.mdx): CLI and server lifecycle.
• [Backups and restore](references/guides/backups-restore.mdx): protection and recovery of application data.
• [Instance migration](references/guides/migrate-control-plane.mdx): 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.