Your code never leaves your infrastructure
For teams whose source cannot go to someone else's model platform. Pier runs inside the cloud account you already own, with open models hosted in your environment, sized for the way your engineers actually work.
The self-serve version of Pier works the way most coding agents do: the agent runs on your machine, and the prompts it builds go out to a hosted model platform. For a lot of engineering teams that is fine. For a bank, a hospital, a defence supplier, or anyone holding client code under a strict contract, it ends the conversation before it starts.
Enterprise inverts it. Rather than sending your code out to the models, we bring the models in to your code. Pier is deployed inside the cloud account and network perimeter your organisation already controls, running open-weight models we host there for you. A coding task never needs to cross your boundary, because everything it touches is already inside it.
The second thing that changes is scale. Subscription tiers exist to make usage predictable for individuals. Teams running agents across large repositories all day are not that, and a monthly credit pool is the wrong shape for them. Enterprise is provisioned capacity on an annual agreement instead, with no per-seat tier to outgrow.
Runs inside your boundary
Pier is deployed into the cloud account your team already owns, inside your own network perimeter. Prompts, source, and diffs stay in infrastructure you control and administer.
Open models, hosted for you
We run open-weight models inside your environment. There is no third-party model platform in the path, so no outside vendor receives your source in order for the agent to work.
Your code is not our training data
Alphabench does not build models, and nothing your team writes is used to train one. Retention is whatever your agreement says it is, including none at all.
Capacity, not a credit pool
Usage is sized to the work your team actually does. Long sessions, large repositories, and many agents running at once are the expected case here, not an overage.
Not subscription bound
No per-seat tiers, no monthly ceiling to hit halfway through a sprint, no top-up packs to remember to buy. One agreement, sized to the organisation.
Your terms, in writing
Data handling, retention windows, region, and access are contract terms you negotiate up front. You are not inheriting defaults set by somebody else's policy page.
Built for heavy workflows
Self-serve
Pro and Max carry a monthly pool of usage credits, which is the right model when one developer is running one agent on one repository. Go past the pool and you buy a top-up pack to keep going.
Enterprise
No credit pool, no per-seat tier, no ceiling to hit halfway through a sprint. Capacity is provisioned around your team's real workloads, so long sessions, very large codebases, and many agents working in parallel are the expected case rather than an overage to explain.
Deployments are scoped per organisation, so limits, regions, retention, and access all get settled as part of the agreement rather than inherited from a public plan.
Common questions
Let us scope it with you
Tell us about your stack, your team size, and the constraints you are working under. We will come back with what an in-boundary deployment looks like for your organisation.
Or email hello@piercode.com directly.