How to Set Up Openship on a VPS or Dedicated Server (2026 Guide)

Openship is an open-source (Apache 2.0) deployment platform that auto-detects your stack, builds an immutable image and ships it to your server over SSH, where an OpenResty edge serves it with automatic HTTPS. This guide installs it on a VPS or dedicated server and deploys a first project, following Openship's installation and quickstart docs. For how it stacks up against the more established option, read our Coolify vs Openship comparison.

Install options

Note: Openship's installation docs show the Windows command with a git.openship.io host; that host does not resolve, and the working one is get.openship.io, as in the table above.

Server requirements

The guidance differs between sources. Bitdoze lists a 2 GB minimum with 4 GB recommended; CloudLinux.ro puts the minimum at 4 GB because Openship builds on first boot. If you plan to build on the server, start at 4 GB. If you build on your own machine or in the cloud and ship images over SSH, a smaller VPS is workable — that off-box build is Openship's main answer to out-of-memory failures on small servers.

How an Openship deploy works

Setup at a glance

Step 1: Install the CLI

curl -fsSL https://get.openship.io | sh

Given how young the project is, pin a specific release rather than taking whatever is latest. Pick a tag from the GitHub releases page and substitute it for <version>:

curl -fsSL https://get.openship.io | OPENSHIP_VERSION=<version> sh

If your shell can't find the openship command afterwards, add its directory to your PATH:

export PATH="$HOME/.openship/bin:$PATH"

Alternatively, install from npm with npm i -g openship — this needs Node 22 or newer.

Step 2: Run the guided setup

openship

Running openship with no arguments starts the wizard. It asks for the admin's name, email and password, and whether the instance is private or public (public needs a domain). It then deploys the platform, creates the admin account and prints the URL. If you'd rather skip the wizard, openship up starts the platform without creating an admin — register the first account in the dashboard straight away.

Compose mode vs bare mode

On Linux with Docker installed, Openship runs as a Docker Compose stack: Postgres, Redis, the API, the dashboard and the OpenResty edge on ports 80 and 443. Anywhere else it falls back to bare mode — a single process with an embedded database. You can force either:

openship up --compose
openship up --bare

On Linux, Openship runs as a systemd service: it restarts if it crashes and starts again on boot.

Step 3: Open the dashboard

openship open

Step 4: Deploy your first project

In the dashboard, create a new project and point it at a GitHub repository or a folder. Openship shows a summary of what it auto-detected — Node, Python, Go, Rust, PHP, Ruby, Java, .NET, Docker or a monorepo — then you click Deploy, watch the live build logs, and get a link to the running app.

The same flow works from a terminal inside your project:

cd your-project
openship init
openship deploy --watch

openship init writes .openship/project.json; --watch follows the logs. For a preview environment, deploy with openship deploy --env preview.

Headless install for automation

For provisioning scripts, the Compose install can run without prompts:

OPENSHIP_ADMIN_PASSWORD='a-strong-password' openship up --non-interactive \
  --admin-email you@example.com --admin-name "You" \
  --domain-kind custom --hostname ops.example.com \
  --acme-email you@example.com --edge migrate

• --domain-kind accepts byo, custom, free (a <slug>.opsh.io address, which needs a connection to Openship Cloud) or none.
• --edge handles an existing proxy on ports 80/443: migrate imports the existing proxy's sites into Openship's edge; takeover stops the existing proxy, so the sites it served stop serving; cancel is the third option.

Running from source with Docker Compose

git clone https://github.com/oblien/openship.git
cd openship
cp .env.example .env
docker compose up -d --build

Review the copied .env before starting the stack, and keep a strong INTERNAL_TOKEN and auth secrets.

Managing the service

Hardening checklist

• Use --no-host-control on a box that only manages remote servers, so it doesn't control its own host.
• Keep a strong INTERNAL_TOKEN and auth secrets.
• Pin the Openship version (OPENSHIP_VERSION) and upgrade deliberately.
• Back up the Postgres volumes.
• Pilot on non-critical workloads first — the docs are thinner and the project is young.

Troubleshooting

Prefer the established route? Our Coolify setup guide walks through the same journey, and the Coolify vs Openship comparison helps you choose.