self-hosted · one VPS or a whole cluster · run by you or your agent

Your servers, run like a platform.

Push an image and it is live, with HTTPS and a database beside it. Add a second machine and it is a cluster. Hand the API key to an agent and it runs the whole thing.

$curl -fsSL https://cubeship.dev/install.sh | sh

One command on a fresh Debian or Ubuntu box. It installs Docker, pulls two images and prints the address to open.

Read the docs GitHub

What you get

One command on a fresh VPS, and the box is running.

Everything Cubeship runs is a container, the daemon included. Nothing else is installed on the host.

  • A dashboard

    At your instance's address, over HTTPS, from the minute the installer finishes.

  • A registry

    docker push to it and the app deploys. The push is the deploy — nothing else to press.

  • Zero-downtime deploys

    The new container has to look healthy before the old one goes.

  • Certificates

    Let's Encrypt, renewed for you, nothing to configure. An sslip.io name until you have one.

  • Databases

    Postgres, MySQL, MariaDB, Redis, MongoDB — one click, wired into the app's environment.

  • Backups

    Every database dumped on a schedule into a bucket off the machine, restored from the same screen.

  • Object storage

    A MinIO on the box, or the S3 bucket you already have. The app gets the keys.

  • Builds

    From a Dockerfile, or from a repository with no Dockerfile at all. A push to GitHub deploys it.

  • More machines

    Add a second server and apps spread across both. Every name still arrives at one door.

  • Internal addresses

    cubeship-<project>-<env>-<app> reaches an app from any other, on any machine, across deploys.

  • Charts

    What every container is using, and what the machine underneath is doing.

  • An API, a CLI and MCP

    Everything the dashboard does, scriptable — and an endpoint an agent drives directly.

The dashboard

A console, not a control panel.

The overview screen of the dashboard
What the machine underneath is doing — CPU, memory, disk and the bytes over its own interfaces, sampled every 30 seconds.

Deploy an app

Three ways in. None of them needs a YAML file.

An app is named project/environment/app, which is also its path in the registry. Create one empty; give it a name on the internet when it has business answering there.

Push an image
$ docker login registry.example.com
$ docker push registry.example.com/shop/api
# the push is the deploy
Run one from anywhere
$ cubeship app create api --image nginx
$ cubeship app deploy api --tag 1.27
# Docker Hub, GHCR, ECR — nothing to set up
Build from a repository
$ git push origin main
# builds here, from a Dockerfile or none# connect GitHub once; every push deploys

Run by you or your agent

The same API, with an endpoint for an agent.

/mcp is authenticated with the same key as the dashboard and the CLI. Point Claude Code, Cursor or whatever you run at it, and it does the work of the dashboard without the dashboard.

mcp.json
{
  "mcpServers": {
    "cubeship": {
      "type": "http",
      "url": "https://cubeship.example.com/mcp",
      "headers": { "Authorization": "Bearer <your-api-key>" }
    }
  }
}

An agent can

  • create a project and an environment
  • deploy an app, then read how the deploy ended
  • read its logs and what its container is using
  • attach a database and set the variables
  • list the servers, the stores and the buckets

Two lines it does not cross

  • read a secret
  • set a container's ceiling

Stateless on purpose: every call carries the key, so nothing an agent opened can be picked up by another. Those two stay with a person.

One VPS or a whole cluster

Add a server, and the instance becomes a cluster.

$ cubeship server add eu-1
# prints the command to run on the new box, credential in it
$ cubeship app place api --on eu-1
$ cubeship app place api --replicas 4
$ cubeship app place api --everywhere

$ cubeship app autoscale api --min 2 --max 8 --cpu 70

  • The new machine dials home

    It publishes no port to the internet, serves no dashboard and needs no certificate of its own. A box behind NAT can report in and be told what to run.

  • Every name still arrives at your instance

    One DNS record, one certificate store. Moving an app between machines touches neither.

  • A private network between them

    Encrypted, and container names mean the same thing on every machine — an app on one reaches a database on another by the name it already had.

  • Scaling takes effect at once

    Four copies, spread. Or hand the count over: a CPU target, a minimum and a maximum.

What reaches the internet

There is no telemetry.

Nothing reports what you deploy, how much you deploy, or that this instance exists. No analytics in the dashboard, no account with anybody. Three things leave the box, and all three are yours to look at.

  1. 01

    Installing and upgrading

    pulls two images from ghcr.io, and asks GitHub which release is newest so it can pin an exact one.

  2. 02

    The running daemon

    asks GitHub which releases exist when an admin opens the update screen. A plain GET, no credential, nothing about your instance in it.

  3. 03

    Let's Encrypt

    for certificates — and only once you have given the instance a domain.