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.
Start a fresh conversation. Replace the highlighted placeholders.
Use openship-deploy to inspect [application repository and intended OpenShip context] and prepare a deployment-readiness plan for [service and desired domain], including configuration and validation needs; do not deploy or change remote settings until I explicitly confirm.
Required inputs
[application repository and intended OpenShip context]
[service and desired domain]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: openship-deploydescription: 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 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
Inspect the repository, existing project link, build entry point, service topology, persistent volumes, and current domain ownership. Use projects and services for commands.
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.
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.
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.
Domains: ownership, DNS, ports, and HTTPS. Reconcile existing ownership before moving a hostname. Domain and SSL failures covers certificates that do not issue.
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.
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.