# OpenShip Guide: Self-Hosted Deployments, Mail, MCP and Beta Caveats

> OpenShip guide to self-hosted deployments, Docker and bare runtimes, mail, MCP permissions, data ownership, installation, and beta caveats.

- **Published**: 2026-07-20
- **Category**: DevOps
- **URL**: https://agentpedia.codes/blog/openship-self-hosted-deployment-platform-guide

---

> **Important callout**

**Bottom line:** OpenShip is one of the more ambitious new self-hosted deployment control planes, but the accurate July 20 label is **public beta**. Test it on a clean disposable VPS or non-critical application before moving production workloads, primary email, or irreplaceable infrastructure.

This guide is based on OpenShip's official X account, documentation, repository, releases, source code, and issue tracker as of July 20, 2026. It is not an installation report, sponsored review, or independent security audit. Vendor claims are labeled, and changing beta status is tied to a date.

## What OpenShip is and what launched

[OpenShip](https://github.com/oblien/openship) is an Apache-2.0 application platform for building, deploying, and operating software on infrastructure you control. It combines a web dashboard, desktop application, CLI, REST API, and Model Context Protocol endpoint with deployment, domain, service, backup, monitoring, and mail-management features.

Do not confuse it with the older `openshiporg/openship` e-commerce order router. The project covered here is `oblien/openship`, announced by `@openshipio`, with `openship.io` as its product site.

The July 17 launch post describes a very broad surface:

| Area | What OpenShip says is available | What to verify yourself |
| --- | --- | --- |
| Application delivery | Git deployments, environments, branch previews, rollbacks, logs, domains, SSL, health checks | Your exact framework, package manager, rollback path, failed-health-check behavior, and build cache |
| Services | Databases, queues, object storage, search, Compose applications | Default credentials, persistent volumes, backup/restore, upgrades, and resource limits |
| Operations | Monitoring, request logs, analytics, secrets, scheduled jobs | Retention, alert delivery, failure visibility, audit history, and recovery time |
| Access | Teams, RBAC, API, CLI, MCP | Least-privilege denial cases, token rotation, revocation, and action attribution |
| Email | Self-hosted SMTP/IMAP, domains, mailboxes, webmail | Port 25, IP reputation, PTR, DNS alignment, bounces, spam placement, and restore |

> OpenShip announced an open-source application platform for deploying and operating apps on infrastructure you own, while naming clustering, load balancing, horizontal scaling, and high availability as coming soon.
>
> -- [@openshipio, July 17, 2026](https://x.com/openshipio/status/2078143909125923137)

The launch post itself separates present features from future work. Multi-server clustering, one-click load balancing, horizontal scaling, and built-in high availability/failover were listed as **coming soon**, not current production capabilities. The repository also names private networking, advanced monitoring, and visual CI/CD pipelines as next work.

At the research cutoff, the GitHub repository showed roughly 4.4 thousand stars and 300-plus forks. Those figures show attention, not operational maturity. The repository was created in March 2026 and was changing rapidly, so version-specific testing matters more than popularity.

## Control plane and deploy targets

The [architecture overview](https://openship.io/docs/architecture/overview) describes your self-hosted service, desktop app, or OpenShip Cloud account as the **control plane**. It owns projects, deployments, domains, environment variables, and permissions. The dashboard talks to that control plane rather than directly managing every target on its own.

A deployment resolves to one of three targets:

| Target | Where the workload runs | How it is reached |
| --- | --- | --- |
| Local | The same machine as the OpenShip control plane | Direct local runtime |
| Server | A VPS, dedicated server, or other machine you connect | SSH |
| Cloud | OpenShip's managed compute | Hosted API and cloud workspace |

OpenShip says it resolves and snapshots the target once per deploy so preflight, build, deployment, and rollback do not disagree about the destination. This is a sensible control-plane boundary, but it does not remove your responsibility to secure SSH identities, host access, container privileges, secrets, and backups.

Data ownership differs by target. Local and server projects are canonical in your own instance database. Cloud projects are canonical in OpenShip Cloud; the self-hosted instance acts as a gateway and does not retain a shadow copy. A project is meant to live fully on one side rather than becoming two copies that need reconciliation.

## Docker, bare and cloud runtimes

OpenShip's [runtime model](https://openship.io/docs/architecture/runtime-model) separates **where an application builds** from **where it runs**. A server deployment can build on the control-plane machine and transfer the output, or build on the target server. Cloud normally builds in a cloud workspace, with an optional local-build/upload path.

The documented build sequence is:

```text
prepare -> clone -> install -> build -> deploy
```

For self-hosted targets, the application can run in one of two isolation modes:

- **Sandboxed:** a Docker container, which is the documented default.
- **Direct:** a bare process supervised by systemd on Linux or `nohup` on macOS, intended for constrained machines where Docker overhead is undesirable.

This distinction changes the meaning of "zero downtime." Docker-sandboxed and cloud versions can overlap: OpenShip starts and checks the new version, switches traffic, and then stops the old one. If the new version fails before the switch, the old container or workspace remains active. A direct process cannot overlap on the same fixed port, so OpenShip stops the old process before starting the new one. The official documentation acknowledges a brief gap and says it restarts the old process if the new one fails.

> **Warning callout**

Do not repeat "zero-downtime deployments" without the runtime qualifier. It applies to the documented sandboxed/cloud switching path, not to every bare-process deployment.

Self-hosted routing uses OpenResty and Let's Encrypt certificates through certbot. That creates an adoption question on servers already running nginx, Caddy, Apache, certbot, or production containers. The current issue tracker included an OpenResty installation report and a code-analysis concern about adopting a server with existing nginx configuration. Prefer a clean disposable machine until coexistence behavior is proven for your setup.

## Install and first deploy

The [installation guide](https://openship.io/docs/installation) lists the following self-hosted baseline:

| Resource | Minimum | Recommended |
| --- | --- | --- |
| CPU | 2 cores | 4 or more cores |
| RAM | 2 GB | 4 GB or more |
| Disk | 20 GB | 50 GB or more SSD |
| OS | Ubuntu 22.04+ | Ubuntu 24.04 |

The simplest documented CLI path is:

```bash
npm install --global openship
openship up
openship status
openship open
```

`openship up` installs a background service, starts the API on port 4000, downloads the dashboard for port 3001, and uses an embedded database when no external database is configured. The guide also documents foreground and API-only modes, a Docker Compose stack, desktop installers, and OpenShip Cloud.

A project workflow is then:

```bash
cd your-project
openship init
openship deploy

# Optional preview deployment
openship deploy --env preview
```

The [quickstart](https://openship.io/docs/quickstart) says `openship init` writes `.openship/project.json`, while deployment supplies a URL and automatic SSL. Its "under 2 minutes" statement is vendor wording, not a timing reproduced for this article.

![Official OpenShip dashboard showing Next.js framework detection and local deployment configuration](https://raw.githubusercontent.com/oblien/openship/main/docs/screenshots/screen.png)

*Official repository screenshot showing framework selection, build commands, a local build target, domain configuration, and a deploy summary. The screen demonstrates interface design, not a completed or successful deployment. [Source](https://github.com/oblien/openship/blob/main/docs/screenshots/screen.png).*

Record the exact version and installation channel during every test. At the July 20 cutoff, npm had already advanced to `0.2.1`, while the newest GitHub Release page remained `v0.1.11`. Release artifacts included macOS, Windows, Linux AppImage, API/dashboard/mail tarballs, and SHA-256 sidecars. Rapid channel drift is normal in a young beta, but it makes "works on latest" an inadequate incident record.

## Services and Compose behavior

The launch post lists PostgreSQL, MySQL, MariaDB, MongoDB, Redis, MinIO, Meilisearch, Qdrant, RabbitMQ, Kafka, ClickHouse, Elasticsearch, and Supabase-style services. The current source catalog is better evidence than the marketing list: it defines images, ports, volumes, and environment defaults for individual templates. Some values are development-oriented and must be changed before exposure--for example, default credentials or disabled security settings can be convenient locally and unsafe in production.

OpenShip also imports `docker-compose.yml` into individual service records. Its [Compose documentation](https://openship.io/docs/compose-services) says only modeled fields--image, build, ports, volumes, environment, command, restart, and dependencies--become editable records. Other Compose constructs such as health checks, networks, labels, anchors, comments, and build arguments are preserved in the source file.

On redeploy, OpenShip describes a three-way reconciliation among:

1. the last imported Compose baseline;
2. dashboard-edited values;
3. the current repository file.

Unedited values can follow the repository. Conflicts with dashboard edits are surfaced as drift, with choices to accept upstream or keep the dashboard value. OpenShip does not write back to the repository, so durable peer-reviewed configuration should still be changed and committed in source control.

Cloud services differ from self-hosted Docker: host-port mappings and Docker volume mounts do not transfer literally to cloud workspaces. Stateful services require explicit backup planning. Before trusting a one-click database, test a full restore into a new environment--not only whether a scheduled backup job reports success.

## Mail server reality

The mail feature is real enough to have a provisioning flow, administration UI, CLI commands, release artifact, and detailed official guide. It is also the feature most likely to be misunderstood as "one click."

The [official email guide](https://openship.io/docs/guides/email-webmail) requires:

- self-hosted OpenShip and a connected clean Ubuntu or Debian server;
- a domain whose DNS you control;
- outbound port 25, which many VPS providers block;
- access to the VPS provider's reverse-DNS controls.

The installer can deploy Postfix, Dovecot, anti-spam tooling, certificates, mailbox administration, health checks, testing, and backups. But it deliberately pauses for actions outside OpenShip:

1. publish MX, SPF, DKIM, and DMARC records;
2. configure PTR/reverse DNS at the VPS provider;
3. wait for DNS propagation and verify it;
4. test inbound mail, SMTP submission, IMAP, and real external delivery.

The guide says the port-25 check warns rather than hard-blocks installation, even though outbound mail will not work until the port is available. It also notes that new domains can initially land in spam. That is why "installed successfully" and "reliably reaches inboxes" are different acceptance criteria.

Recent official replies said Amazon SES support was planned, not already shipped. The safest mail evaluation uses a non-production domain and measures delivery to multiple providers, message headers, DKIM alignment, DMARC reports, bounce behavior, queue handling, backup/restore, abuse controls, and IP reputation. Do not migrate a primary business domain merely because mailbox creation works.

## MCP and permission scoping

OpenShip exposes a stateless Streamable HTTP JSON-RPC 2.0 endpoint at:

```text
POST /api/mcp
```

The [MCP documentation](https://openship.io/docs/mcp) supports OAuth 2.1 discovery with PKCE and browser consent, or a personal access token for clients without OAuth. It says every tool call passes through the same permission system as REST access. Read-only and resource-scoped grants can restrict projects, servers, and repositories below the user's own maximum access.

An important limitation is easy to miss: MCP tools are derived from API routes that explicitly opt in. The MCP surface is therefore a curated permission-tagged subset, not an automatic agent wrapper around every OpenShip capability. Always call `tools/list` with the exact test identity rather than assuming a dashboard action is available to an agent.

A safe agent test should prove denials as well as successes:

- read-only identity can inspect but not deploy;
- project-scoped identity cannot discover another project;
- server-scoped identity cannot operate an ungranted server;
- revoked credentials fail immediately;
- deployment and secret-changing actions have usable attribution.

Never put a real PAT, API key, SSH key, or mail password in an article, screenshot, repository, or agent prompt.

## Data ownership, security and export

Self-hosted data can use embedded PGlite or a configured PostgreSQL server. The [data-ownership documentation](https://openship.io/docs/architecture/data-ownership) says local projects, deployments, domains, environment variables, and logs remain in the local instance when cloud features are not used.

Owners can export an entire instance through the dashboard, CLI, or API. Secret values are encrypted at rest. When an export includes secrets, OpenShip says it derives a key from a user passphrase with scrypt and seals the bundle with AES-256-GCM; the destination re-encrypts imported secrets under its own key. An export without a passphrase omits secrets, and a lost passphrase cannot be recovered. The documented import limit is 500 MB.

That design is promising, but a design description is not a restore test. Export a disposable instance, destroy it, restore it elsewhere, re-enter or unlock credentials, and verify deployments before considering the portability requirement met.

On July 20, OpenShip also posted that the desktop app can control infrastructure through secure tunnels instead of requiring a publicly exposed management API:

> OpenShip said security is a major focus and described its desktop control path as using secure tunnels rather than publicly exposed management APIs.
>
> -- [@openshipio, July 20, 2026](https://x.com/openshipio/status/2079231758520717800)

Treat "continuously auditing" as a vendor statement. No public independent audit report was identified in the official material reviewed for this article. Also distinguish a management-plane tunnel from the runtime itself: deployed applications, Docker, OpenResty, certificates, and any services still create host-level attack surface that must be patched and monitored.

## Beta, live availability and current caveats

OpenShip's own account gave the clearest status statement on July 20:

> OpenShip said it was releasing a major patch, explicitly described the product as still in beta, and said it was working toward an upcoming stable release.
>
> -- [@openshipio, July 20, 2026](https://x.com/openshipio/status/2079052569112879342)

That status should override looser marketing phrases such as "production-ready core." A production-ready subset and a beta product can coexist, but the beta label is the safer expectation for adoption decisions.

The issue tracker at the cutoff included reports involving desktop-to-SSH Docker operations, SSH/SFTP session exhaustion, OpenResty installation, desktop login, documentation links, and adoption of servers with existing web-server configuration. Issues are reports, not automatic proof that every user is affected. They are still valuable for selecting test cases and avoiding a misleading happy-path-only review.

A direct availability check at approximately 18:10 UTC on July 20 returned HTTP 404 for both `https://openship.io/` and `https://openship.io/docs`, while the GitHub repository returned HTTP 200. Several users reported the same outage. This is a timestamped snapshot, not a claim that the site is permanently unavailable; use repository docs and release artifacts when the site is down.

## Sandbox evaluation plan

Use a fresh non-critical environment and preserve evidence for every step.

### 1. Pin the test

Record the OpenShip version, install source, operating system, Docker/OpenResty versions, target type, isolation mode, build location, repository commit, and time. Do not mix npm `0.2.x` behavior with a `v0.1.11` desktop artifact in one conclusion.

### 2. Deploy a disposable application

Choose a small representative application with a health endpoint, environment variables, database migration, persistent data, background task, custom domain, and TLS. Test both a successful deployment and intentional install/build/start failures.

### 3. Exercise lifecycle recovery

Create a preview, promote or redeploy, fail a health check, perform a rollback, restart the target, and restore a backed-up service into a new environment. Measure recovery from the operator's perspective rather than trusting status labels.

### 4. Prove permission boundaries

Create owner, operator, read-only, and scoped agent identities. Attempt allowed and denied API/MCP actions. Rotate and revoke every credential used in the test.

### 5. Test server adoption safely

Use a clean VPS first. If you later consider an existing host, snapshot it and inspect ports 80/443, existing nginx/OpenResty/Caddy configuration, certificates, Docker networks, volumes, and running services before allowing OpenShip to modify shared state.

### 6. Treat mail as a separate project

Use a non-production domain. Confirm port 25 and PTR control before installation. Verify MX/SPF/DKIM/DMARC, send to several mailbox providers, inspect authentication results and spam placement, test bounces and abuse handling, then prove message and configuration restore.

### 7. Compare outcomes--not logos

For Coolify, Dokploy, Railway, or another existing platform, compare your own deployment time, failure visibility, rollback, backup restore, least privilege, maintenance burden, and recovery objectives. Avoid an invented feature matrix whose rows change every few days during beta.

## Use it, test it or wait

**Test OpenShip now** if you value open source, self-hosted control, multiple interfaces, scoped agent access, Compose reconciliation, and the option to deploy locally, over SSH, or to a managed cloud--and you can tolerate rapid beta changes.

**Use it only for bounded workloads** after your exact install, deploy, rollback, restore, domain, permission, and update paths pass. Keep independent backups and a documented exit path.

**Wait** if you require independently demonstrated multi-node high availability, mature operational support, stable release-channel alignment, an established security audit record, or primary-email deliverability you cannot risk.

The project is technically interesting and unusually broad. The responsible conclusion is not "replace your platform immediately"; it is "run a disciplined sandbox evaluation and let recovery evidence decide."

## FAQ

### Is OpenShip ready for production workloads?

OpenShip describes its core as production-ready, but its official account also called the current product a beta test. Evaluate the exact install and deployment path in a sandbox before using it for a critical workload.

### Can OpenShip replace Coolify, Dokploy or Railway?

It may cover overlapping deployment needs, but a safe decision requires testing your own application, rollback, backups, domains, monitoring, permissions and failure cases rather than relying on a broad feature checklist.

### Does OpenShip provide zero-downtime deployments?

Official runtime documentation says Docker-sandboxed and cloud versions can overlap during traffic switching. Direct bare-process deployments cannot overlap on the same port and therefore have a brief gap.

### Is the OpenShip mail server really one click?

The wizard automates installation, but the official guide still requires an appropriate server, open outbound port 25, DNS records such as MX, SPF, DKIM and DMARC, and a PTR record configured through the VPS provider.


---

[Join the Agentpedia newsletter](https://agentpedia.codes/blog)
[Browse related Agentpedia articles](https://agentpedia.codes/blog)

## Official sources

- [OpenShip launch post](https://x.com/openshipio/status/2078143909125923137)
- [OpenShip beta status post](https://x.com/openshipio/status/2079052569112879342)
- [OpenShip security architecture post](https://x.com/openshipio/status/2079231758520717800)
- [OpenShip GitHub repository](https://github.com/oblien/openship), [releases](https://github.com/oblien/openship/releases), and [issue tracker](https://github.com/oblien/openship/issues)
- [Installation guide](https://openship.io/docs/installation) and [quickstart](https://openship.io/docs/quickstart)
- [Architecture overview](https://openship.io/docs/architecture/overview), [runtime model](https://openship.io/docs/architecture/runtime-model), and [data ownership](https://openship.io/docs/architecture/data-ownership)
- [Compose services](https://openship.io/docs/compose-services)
- [Email and webmail guide](https://openship.io/docs/guides/email-webmail)
- [MCP documentation](https://openship.io/docs/mcp) and [REST API documentation](https://openship.io/docs/api)


---

- [All articles](https://agentpedia.codes/blog)