# Deployment options
Where Plansmith runs, and how it reads a Git server that only answers inside your network.
Plansmith is a hosted service. What varies between teams is where your Git server lives and how much
of it stays on your side of the firewall.
## Plansmith cloud [#plansmith-cloud]
How everyone runs Plansmith today. The application is hosted, your workspace data lives in a managed
Postgres database, and there is nothing to install.
Which providers process your data, and where, is stated in the
[privacy policy](/privacy). This page does not keep a second copy of that list, because two copies
drift and one of them ends up wrong in front of a customer.
## Your Git server, inside your network [#your-git-server-inside-your-network]
GitHub Enterprise, self-managed GitLab and Bitbucket Data Center all connect the same way a cloud
host does, and grounding a plan in your code works the same once connected.
**Self-hosted Git servers are a Team and Enterprise capability**, and registering one takes an owner.
What differs is whether Plansmith can reach the server at all.
### Reachable on public HTTPS [#reachable-on-public-https]
Plansmith connects directly. This covers all three providers.
The part worth reading if you are reviewing us: every request checks the address the hostname
actually resolved to, inside the same lookup that makes the connection. A name cannot resolve to
something harmless during a check and something internal a moment later.
* Loopback, private and link-local addresses are refused.
* Cloud metadata endpoints are refused.
* Carrier-grade NAT, unique local IPv6 and multicast ranges are refused.
* Plain HTTP is refused. Self-hosted means public HTTPS.
Register the server under **Settings → Connectors**, then connect it the way you would a cloud host.
See [Connecting a repository](/docs/connecting-a-repository) for the product flow.
### Not reachable from the internet [#not-reachable-from-the-internet]
The managed broker is a small container you run inside your network. It dials **out** to Plansmith
and asks for work, so:
* there is **no inbound firewall port**, and nothing for you to open;
* your Git credential never leaves your side: the container authenticates to your server with a
service account you create, and that account is the bound on everything the broker can read.
Be clear on what the broker does, because "outbound only" is about connections, not about
intent. The work still originates with Plansmith: the container polls for a request, runs it against
your server, and sends the result back so the agent can ground a plan in it. What stays on your side
is the credential and the network position. What travels is the content the agent asked for, the
same as any other connected repository.
**The broker relays GitLab.** Its target list holds GitLab and nothing else today. If you run GitHub
Enterprise or Bitbucket Data Center and your server answers on public HTTPS, use the direct path
above. If it does not, talk to us: there is nothing to run yet.
[The broker setup guide](/docs/developers/broker) is written for the person running the container,
not for a Plansmith user. Hand it over as-is.
## Self-hosted Plansmith [#self-hosted-plansmith]
For an Enterprise agreement we will discuss running Plansmith inside your own environment. What that
looks like depends on your constraints, so it is scoped per agreement rather than described here.
Start with a conversation. See [Enterprise features](/docs/enterprise).
## If you run a corporate proxy or an egress allowlist [#if-you-run-a-corporate-proxy-or-an-egress-allowlist]
Allow these:
| Host | What it serves | Who needs it |
| ------------------ | ----------------------------------------------------------------- | ------------------------------- |
| `app.plansmith.co` | The product | Everyone |
| `www.plansmith.co` | The marketing site, including these docs and demo booking | Everyone |
| `*.supabase.co` | Sign-in and live plan updates, which the browser fetches directly | Everyone |
| `api.plansmith.co` | The REST API | Teams using the API or the CLI |
| `mcp.plansmith.co` | The MCP server | Teams connecting a coding agent |
The Supabase host is the one people miss. The app signs you in and streams plan updates from it in
the browser rather than through our API, so a proxy that allows only `plansmith.co` leaves your team
staring at a login screen.
The broker adds nothing inbound. Outbound, it talks to exactly two places: `app.plansmith.co`, and
the Git server you point it at inside your own network. Point it at the API or the MCP host instead
and it refuses to start, naming the host to use.
## Side by side [#side-by-side]
| | Cloud | Your Git, direct | Your Git, broker | Self-hosted |
| -------------------- | ------------------- | ------------------------------------------------ | ----------------------------------------------- | ---------------- |
| **Application runs** | Plansmith cloud | Plansmith cloud | Plansmith cloud | Your environment |
| **Your Git lives** | Anywhere | Your server, public HTTPS | Your network, no inbound port | Your network |
| **Providers** | All | GitHub Enterprise, GitLab, Bitbucket Data Center | GitLab | By agreement |
| **We hold** | Your workspace data | Plus an OAuth token and whatever the agent read | Plus a broker token and whatever the agent read | By agreement |
| **What it takes** | Sign up | Team plan, an app registered on your server | Team plan, run a container | Talk to us |
The product flow for grounding a plan in your code.
The runbook for the person who runs the container.