Supported environments & limitations
Plan a deployment with Shipown 0.1.0-rc.10: check the target, prerequisites and recovery options first.
Deployment scope and verification status
Shipown guides supported app deployments from your desktop to a Linux VPS or bare-metal server you control, over SSH. A VPS rented from a cloud provider is a valid target.
The desktop download supports Windows and Linux; use the installers listed on the download page. Desktop compatibility and server compatibility are separate requirements.
The following describes implemented deployment paths. An RC deployment matrix with exact desktop OS, server OS version, architecture and runtime versions has not yet been verified in this release record. Local automated checks do not establish that a particular VPS setup passed an end-to-end deployment.
| App type | Requirements | Limits |
|---|---|---|
| Node / Next.js | Compatible Node.js, package manager and PM2; correct build/start commands and application port. | Framework detection is a proposal to review. A process or listening port does not prove the public app works. |
| Static sites | Build output or static files, Nginx, and permission to write the managed web root. | A completed file deployment without a configured domain route may not be publicly served. |
| Dockerfile / Compose | A compatible project, Docker daemon access, Compose when used, and explicit ports, environment values and volumes. | Images must match the target architecture. A Docker deployment without a domain can be reachable only on server loopback. |
Setup helpers contain apt, dnf/yum and apk paths. That does not certify every Ubuntu, Debian, RHEL-family or Alpine version. Windows and macOS are not deployment server targets.
What you prepare
- Provision the Linux server, arrange backups for persistent data, and make SSH reachable from your desktop.
- Supply the host, port, username and a supported private key with passphrase or password. Review the SSH host-key and credential limitations before connecting.
- Provide a local project or accessible GitHub repository, its install/build/start commands, output directory, runtime version, application port and environment values.
- Install runtime prerequisites or review the relevant setup helper before running it. Package installation and changes to Nginx, certificates or the static web root need root or suitable passwordless sudo permissions. Some setup actions also upgrade system packages.
- Configure DNS, server and provider firewall rules, and any external database or service. Public HTTPS requires a correctly routed domain, reachable challenge ports and certificate service access.
- For Build on this PC, install local build tools. Node and container builds need Linux Docker and compatibility with the server architecture; native Node artifacts also depend on Node ABI and libc.
- Activate a valid licence and keep the desktop app running and the computer awake through deployment. Check the public URL and expected content after the first release and every update.
Direct SSH and hosted services
Deployment commands travel from the desktop to your server over SSH without a Shipown deployment relay. The app also uses hosted licence activation and periodic validation, with limited offline grace, and hosted update checks. GitHub, dependency or image registries, certificate services and optional AI providers depend on the features you use.
You maintain your application configuration and any custom build commands or container definitions. Deployment duration depends on the project, machine, network and cache state. See Architecture for the service boundaries.
Known limitations and recovery
- Deployment completion is not proof of public URL health. Local checks can accept a running process or listening port; routing and certificate failures may be warnings. Verify the expected HTTP response and release content yourself.
- Restoring an earlier release requires retained files or images and a reachable server. Recovery attempts can fail. Release rollback does not undo database migrations, persistent volume changes or changes to external services.
- After an interrupted SSH connection or desktop exit, inspect server state before retrying. A lost connection does not establish that the remote work stopped, completed or recovered.
- Ordinary SSH deployment and terminal connections do not currently enforce saved host-key verification in the reviewed source. The IP recovery check is separate. This needs release validation and resolution before a universal host-key validation claim.
- Log output can contain values printed by your application. Inspect and redact it before sharing recordings or reports. Credential storage behavior varies by secret and OS keyring availability.
- Deployment history is local to the desktop. Monitoring needs the app running and the computer awake. Deployment on git push is not automatic.
Use the troubleshooting and recovery steps to reconcile a failed or interrupted release. RC validation remains pending for live success, failure, interruption, data preservation and credential redaction scenarios; this is not a statement that those tests failed.