Deployment options

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

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. 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

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.

What differs is whether Plansmith can reach the server at all.

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 for the product flow.

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 setup guide is written for the person running the container, not for a Plansmith user. Hand it over as-is.

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.

If you run a corporate proxy or an egress allowlist

Allow these:

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