Health

The Health API is how anything outside Openship checks that an instance is alive and learns how it's set up — its version, auth mode, and which cloud (if any) it targets. Load balancers and Docker health checks hit GET /api/health; the CLI and dashboard read GET /api/health/env to decide which login flow to show. From the terminal it's the openship status command. Both routes are available on every instance (self-hosted, desktop, and cloud).

Liveness probe

GET /api/health

Returns 200 with a fixed body as long as the process is serving requests. Use it as a container or load-balancer health check — it touches no database and never requires auth.

curl "$OPENSHIP_URL/api/health"
# → {"status":"ok","timestamp":"2026-07-19T04:29:00.000Z"}

Deployment info

Static, cache-friendly description of how the instance is configured. Clients read this to pick the right login flow and to reach the correct cloud endpoints — the dashboard uses these values rather than a hard-coded table. Reads that depend on the database (teamMode, migration fields) fall back to safe defaults if the settings table is unavailable mid-migration, so this route stays up.

The response shape:

const result = await ship.system.info();
console.log(result);

curl "$OPENSHIP_URL/api/health/env"

Prop

Type

Errors

Connection refused / timeout

These routes never return an auth or permission error — a failure means the process isn't reachable (wrong host/port, container still starting, or the instance is down). openship status reports this as Cannot reach the API at <url>. Confirm the instance is running and the URL is correct, then retry.

Operations

Resource methods

Operation	SDK	REST API
Read installation and deployment-mode information.	`system.info()`	`GET /api/health/env` `Public`

HTTP endpoints

Operation	SDK	REST API
Liveness probe — returns `{ status, timestamp }`.	HTTP only	`GET /api/health` `Public`