OpenShip deployment: where your app runs and what to test

Written by

OpenShip can manage deployment to a server you control. The key distinction is between the dashboard that starts a deployment and the machine that runs the public application.

Published on

OpenShip deployment: where your app runs and what to test

Updated

Does closing the desktop app stop the website?

In the SSH deployment model, the desktop control plane connects to a remote server. The application runs on that server. Closing the local dashboard is different from stopping its remote containers. The current OpenShip README distinguishes desktop use from an always-on control plane for team access and automated deployment.

That distinction matters during troubleshooting. A successful SSH connection proves management access. It does not prove that visitors can reach HTTPS, that DNS points to the right address or that every dependent service is healthy.

From code to a public app
Deployment moves code to the server, then routes a public domain to the running application.

Follow one request through the stack

For a typical multi-service site, a browser reaches the public edge. The edge routes the hostname to a web service; that service may call an API, which reads a database or object store. Each hop has its own configuration.

OpenShip documents Compose applications and its edge. Check the guide for your installed release. If an edge already owns public ports 80 and 443, a second proxy must not try to bind those same host ports. Internal HTTP behind a TLS-terminating edge can be intentional.

A deployment checklist that catches real failures

Check Evidence to collect
Source version The deployed commit matches the release you tested
Build configuration Public URLs are not left as localhost
Runtime configuration API, database and storage endpoints resolve inside the deployment
Public route The real domain returns the expected page over HTTPS
Data persistence Records and uploads survive a service restart
Recovery A backup can be restored and the previous release is known

Test a workflow, not only the home page. Publish a draft in a test environment, open it through the public route and verify an uploaded image. Read-only page checks cannot establish that writes work.

Why build-time and runtime variables differ

A frontend build may embed a value before the container starts. Setting a runtime variable later cannot change text already compiled into the bundle. Conversely, server-side code can read runtime configuration on each request. Document which mechanism owns your canonical domain and API address, then check the rendered HTML.

What remains your responsibility?

A deployment platform reduces repeated setup. You still own the application settings, access rules, backups and release validation. Before a migration, read OpenShip's backup and restore guidance and test the process on disposable data.

For a concrete Astro and Rust application, see Wegweiser Leben. For a new build, explore custom web applications.

Talk to me

Tell me what you have in mind. I usually reply within one working day.