PortBayvsWarp

Only for part of what Warp does, and it is worth being blunt about which part. Warp is a terminal, a coding agent and a cloud orchestration platform for agent fleets; PortBay is none of those things. It is a local development environment with a task board on top. If you want a better terminal, agents running on Windows or Linux, hundreds of runs in parallel on cloud infrastructure, or SSO and audit trails for a team, PortBay does not replace Warp and you should keep using it. PortBay replaces the missing layer underneath a local agent run: the runtime, the database, the HTTPS domain and the mail catcher that let the agent verify its own work.

A lot. It runs on Windows and Linux as first-class platforms. It ships a terminal, which PortBay does not. Through Oz it launches agents on cloud VMs, on self-hosted Docker on your own machines, or unmanaged in your CI and Kubernetes, running hundreds in parallel and orchestrating subagents on long tasks — triggered from Slack, Linear, Jira, GitHub or a schedule, with a single pane of glass across a whole team, per-run audit links, model routing across frontier and open-weight models, SAML SSO, spend caps and enterprise analytics. It has a free tier where you can bring your own inference, and 64,000-plus GitHub stars. PortBay has none of that and is not on a path to it.

PortBay provisions the application the agent works on. A PortBay card runs against a project with a pinned PHP or Node runtime, a database from seven engines with an isolated data directory and injected connection variables, trusted HTTPS on a real .test domain via mkcert, captured outbound mail and a one-click Cloudflare tunnel — so the agent can apply a migration, load the page and read the email it just sent. It imports the sites already configured in Laravel Herd, ServBay, MAMP or Laravel Valet. And it confines each local run in a macOS Seatbelt profile with a per-project network policy, which is a stronger guarantee than an allowlist for something running on your own machine. Warp's cloud environment is a repo, an image and startup commands; its docs describe no managed databases, local HTTPS, mail capture or tunnels. On the agent side it is deliberately unopinionated in the same way Warp is: it dispatches 11 out of the box — Claude Code, OpenAI Codex, Cursor, Gemini, Aider, Copilot CLI, OpenCode, Amp, Qwen Code, Antigravity and Ollama — plus any other CLI via a Custom command template.

The client is. Warp open-sourced its core product on 28 April 2026 — github.com/warpdotdev/Warp, AGPL-3.0, with the warpui and warpui_core crates under MIT, and OpenAI as flagship sponsor of the repository. The repo has roughly 64,800 stars as of 2026-09-06. The Oz cloud platform is a service, not the open-source part, though Warp does let Enterprise customers run agent execution on their own infrastructure. PortBay is AGPL-3.0 as well, on a much smaller and younger repository.

Cost depends entirely on how much inference you buy from each tool, so compare honestly. Warp has a real $0 tier that includes the terminal, Warp Agent CLI access and bring-your-own inference; paid plans start at $20/month ($18 annual) for 1,500 credits, with Max at $200/month and Business at $50 per user. Credits are agent usage, so heavy use moves the bill. PortBay is $10/month flat, free for up to 6 projects, and free for life with a merged qualifying pull request or a GitHub sponsorship — and it never sells you inference, because it dispatches the Claude Code or Codex subscription you already have. If you already pay for an agent CLI and want a predictable line item, PortBay is cheaper. If you want one vendor to handle models and billing too, Warp's tiers are doing more work for the money.

Warp's strength is cloud isolation: an Oz run happens in its own environment on Warp's VMs, in a Docker container on a machine you control, or in your CI, well away from your working copy. Locally, Warp's documented controls are agent profiles with per-action autonomy — reading files, creating plans, executing commands, calling MCP servers — plus a command allowlist and a denylist that overrides everything else. Those are approval gates rather than an operating-system boundary. PortBay only runs locally, and puts a boundary there: a generated macOS Seatbelt profile per project confines writes to the project folder and sets a network policy of blocked, loopback, outbound or full, logging denials line by line, while the code itself sits in a throwaway git worktree. Different threat models, and the right one depends on whether the risky run is on your laptop or somewhere else.

Yes. They store state in different places, dispatch the same agent CLIs, and neither claims your git remote. The arrangement that makes sense: Warp stays your terminal and your fleet, and PortBay owns the local project — the runtime, the database, the .test domain — so the cards that need a running application have one. An agent you start from Warp inside a PortBay project sees the same environment variables and the same live services, because PortBay set them up.