Why Ship Exists

Every developer has been there. You write your code, it works locally, and then you spend the next hour clicking through a cloud provider's dashboard trying to provision a server, configure firewalls, set up SSH keys, and get your app deployed.

The Dashboard Problem

Cloud dashboards are designed for humans who operate infrastructure full-time. They're feature-rich, deeply nested, and full of options you don't need for a straightforward deploy. For a developer — or an AI agent — that just wants to get code running on a server, they're friction.

The context switch alone is costly. You leave your terminal, open a browser, navigate menus, wait for pages to load, and manually copy values back and forth. This breaks flow for humans and is simply impossible for AI agents.

Terminal-First

Ship takes the opposite approach. Everything happens in the terminal. One command to create a server. One command to deploy. One command to check status. No browser tabs, no clicking, no copy-pasting IPs.

The output is machine-friendly by design — KEY=VALUE pairs that any script or agent can parse. Add --json when you need structured data.

Built for Agents

Ship was designed from the start to work with AI coding agents. When an agent like Claude Code or Cursor needs to deploy your project, it can invoke Ship commands directly. No browser automation, no screen scraping, no API wrangling — just clean CLI calls with deterministic output.

The agent reads the output, understands the state, and moves on. Ship keeps the infrastructure layer thin so the agent can focus on what it does best: writing and shipping code.

Minimal by Design

Ship doesn't try to be Terraform or Pulumi. It's not an infrastructure-as-code framework. It's a single binary that does exactly what a developer or agent needs to get an app live on a server: provision, deploy, monitor, rollback.

That's it. No state files to sync. No plan/apply cycles. No YAML schemas. Just commands that do what they say.