OpenCode for Regulated and Enterprise Teams

You can deploy the free OpenCode client on company-controlled machines and connect it to an approved model endpoint. OpenCode Enterprise is a separate commercial offering for organization-wide configuration, identity integration, and a vendor relationship. Buying Enterprise is not required simply to use your own model gateway.

For me, the attraction is control over where requests go and how the agent runs. That control brings operating work. Someone must maintain the configuration, credentials, updates, and evidence that the chosen deployment meets the team's requirements.

For an initial product shortlist, our guide to AI coding tools covers OpenCode and the proprietary alternatives. This guide focuses on evaluating the OpenCode deployment path.

Can OpenCode Meet Your Data-Handling Requirements?

OpenCode can support a controlled deployment, but the answer depends on the model endpoint, tools, storage, and network controls you configure. A locally installed agent can still send code to a hosted model or remote MCP server. Evaluate that complete path before deciding whether the free client or Enterprise service fits.

Define Where Code Is Allowed to Go

Most tool evaluations start with a feature grid and arrive at the security questions late. Reverse it. Write down the one requirement that would disqualify a tool outright, and test that first.

• Code must never leave our network: use inference on a local machine or an internal model server, with other outbound paths controlled.
• Code may leave, but must not be retained: provider retention terms decide it.
• We need audit evidence for a regulator: request evidence for the actual services and controls in your deployment.
• We need it approved this quarter: published compliance documents win on speed.

OpenCode gives you configuration options for the first two requirements. On the third it is weaker: its public Enterprise page states no certification and links no audit report, so that evidence has to be requested under the Enterprise agreement rather than assumed from a provider's paperwork.

Map Every Outbound Path

OpenCode does not store code or context on its own service by default. Session data stays on your machine, and /share sends a shared conversation to OpenCode's hosting service.

A single session can reach the network through several independent paths, and each one has its own destination, credentials, and logs.

Path	Goes To	Control
Model requests	Provider or localhost	Provider config
Remote MCP servers	Third-party endpoints	Disable per server
Package installs	Public registries	Permission rules
Git operations	Your remotes	Deny rules on push

Run that list before a pilot, not after. A team that verified the model path and forgot the MCP path has verified a quarter of its perimeter and reported it as the whole thing.

The local-inference half of this has its own walkthrough in OpenCode local models with Ollama, including where the offline claim actually holds.

Run OpenCode Inside Your Own Infrastructure

The deployment story is the strongest part of the case. OpenCode runs on machines you already own, against a gateway you already control, with no vendor tenancy in the middle.

That gives a security team three things a hosted product usually cannot:

1. The agent's source is readable, so behaviour can be verified rather than trusted.
2. The model endpoint is yours, so retention is governed by your own contract.
3. Nothing is stored on OpenCode's service by default, so there is no vendor-side copy to reason about.

The cost is that operating it becomes your job. Upgrades, availability, and the gateway's own monitoring all land on an internal team, and a fast-moving open-source release cadence means those upgrades arrive often.

What OpenCode Enterprise Adds

The open-source tool is not the only option any more, and evaluations written a few months ago miss this. OpenCode sells a per-seat Enterprise product, with a sales and implementation contact rather than a community forum as the only route in. No seat price is published, so the figure has to come from a sales quote.

Enterprise adds	What It Covers
Central config	Organization-wide defaults
SSO	Gateway credentials via your identity provider
Internal gateway	Only yours; other providers disabled
Pricing	Per seat, unpublished; quote from sales
Vendor contact	Sales and implementation

That changes the shape of the decision. Organization-wide enforcement and identity are now a product you can buy rather than something you assemble, and bringing your own gateway means OpenCode adds no token charge on top of what your provider bills.

Internal Gateway Versus Bringing Your Own

The internal-gateway row is the one most likely to be misread, so read it slowly. Pointing OpenCode at a gateway you run is already free: a provider entry in opencode.json sets the base URL and the open-source tool sends its requests there. Buying Enterprise is not how you get a self-hosted endpoint.

That entry is the whole mechanism, in the shape OpenCode's provider documentation gives for an OpenAI-compatible /v1/chat/completions endpoint. A gateway serving /v1/responses instead takes the @ai-sdk/openai package rather than the one below. Substitute your own gateway URL and the model IDs it serves:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "gateway": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Internal gateway",
      "options": {
        "baseURL": "https://llm.internal.example.com/v1"
      },
      "models": {
        "your-gateway-model-id": {
          "name": "Internal gateway model"
        }
      }
    }
  }
}

No OpenCode Enterprise agreement is needed for that. Commit the file and every clone receives the same gateway configuration, which is exactly why the Enterprise value has to be something other than the endpoint itself.

What the Enterprise central config adds is stated in three parts on the same page. It is set up once for the whole organization rather than repository by repository. It can integrate with your SSO provider so OpenCode obtains the gateway credential through your existing identity system.

The third part is the one procurement cares about: the central config can be set to use only your internal gateway, with all other AI providers disabled. That is the centrally managed restriction OpenCode Enterprise offers.

One thing the public docs do not state is which configuration layer carries that central config, and the answer decides how strong the restriction is. OpenCode publishes an eight-source precedence order in which remote organizational config from .well-known/opencode loads first as a base layer that global and project files can override.

Managed config files and macOS MDM preferences sit at the top of that same order and are described as not user-overridable. The Enterprise page does not say which layer it uses, so ask before you write "other providers are disabled" into a control description.

What none of this changes is the evidence question set out in Define Where Code Is Allowed to Go. Enterprise-specific liability and support terms are not published on the Enterprise page, so ask how the public Terms of Use relate to the Enterprise agreement.

Choose Between Shared Defaults and Enforcement

Access control for a local agent is mostly your existing controls: who can log into the machine, who holds the provider credential, and who can push to the repository. The agent inherits all three rather than replacing them.

Shared configuration is where a team gets consistency. A project-root opencode.json is documented as safe to commit and takes highest standard precedence, so every clone starts from the same providers and permission rules.

OpenCode 2 makes this distinction explicit: ordinary settings do not prevent users from adding providers or tools; enforced restrictions belong in policies at an appropriate managed or system layer.

Be precise about what that buys you. A checked-in file gives the team shared defaults that everyone can inspect, and it can still be changed or overridden locally, so a repository config is not enforcement. Organization-wide enforcement comes from Enterprise central config or from admin-controlled managed settings.

Credential handling deserves one explicit rule. Provider keys belong in the environment or a secrets manager, never in a configuration file that gets committed, because the whole point of the shared file is that it is readable by everyone.

Permissions Are Your Policy Surface

OpenCode ships with permissive settings. Out of the box it will run most operations without asking, and you tighten it yourself. For an individual developer that is a preference. For a regulated team it is the single most important configuration step.

Write the rules before the pilot, not after the first incident. A deny rule on pushes, an ask rule on anything that installs software, and an allowlist for the commands your build actually needs covers most of what a review board asks about.

The rule syntax, ordering, and the bounded-loop guards are covered in the advanced OpenCode guide. Treat that file as the written policy, and keep it in review like any other control.

What Procurement Will Ask For

A vendor relationship now exists, so the old "there is nobody to ask" answer is wrong. What is still missing is the Enterprise-specific document set, unchanged from the perimeter check.

The Status column below is the at-a-glance version. Published means the answer is in the public docs, request means ask the vendor for it during contracting, and self-managed means it never was theirs to answer.

Question	Status	Where the Answer Comes From
Audit report	Request	Not linked; ask Enterprise sales
Data residency	Depends on the whole deployment	Your own infrastructure and model provider
Access control	Published	SSO via Enterprise central config
Enterprise-specific terms	Request	Request during Enterprise contracting
Support commitment	Request	Not stated; ask Enterprise sales

Disabling sharing closes one data path, not every path. The model gateway, its upstream providers, MCP servers, logs, Git remotes, and package tools all need locations and retention policies that match your requirements. An internal gateway can still forward requests outside your network.

A hosting or model provider's attestation covers that provider's service, not OpenCode's central config, SSO, supply chain, or contract. Do not let one stand in for the other in a submission.

Every row that stays yours is real work with a real owner, so name that owner in the proposal rather than leaving the cell to imply somebody has it.

Where a Commercial Vendor Wins

A commercial editor offers published compliance evidence, single sign-on, directory provisioning, and audit logs, most of them admin-configured rather than on out of the box. For a team whose blocker is a procurement calendar rather than a network boundary, that is still the faster path.

The trade runs the other way when the requirement is absolute. If code cannot leave the perimeter, a hosted agent that routes requests through a vendor backend cannot satisfy it, however good the paperwork is.

The full head-to-head on that trade, including pricing and the agent layer, is in Cursor vs OpenCode.

Decide on the Requirement You Can Prove

Pick the smallest deployment that satisfies your hardest requirement. For most teams that is OpenCode against an internal gateway with checked-in permission rules, not a full air-gapped build that nobody has the hardware to run well.

Add Enterprise when the requirement is organization-wide enforcement, SSO, or a vendor contract, and price that per seat against what assembling the same controls would cost you.

Start from the OpenCode overview for the basics, and use the advanced guide to write the permission rules your pilot will be judged on.

FAQ

Vendor facts on this page were checked against OpenCode's own documentation on August 9, 2026. The Enterprise product details, the internal-gateway distinction, and the config precedence order were re-verified on August 10, 2026.

Is OpenCode SOC 2 certified?

OpenCode’s own SOC 2 certification is unverified in the public Enterprise material reviewed for this guide; request a current report rather than assuming certification. Your hosting and model providers have their own attestations, and those cover their services only. They say nothing about OpenCode's central config, SSO, supply chain, or contractual controls.

Does OpenCode store our code?

OpenCode does not store code or context on its service by default. Session data stays local, and the share command sends that conversation to OpenCode's hosting service. Your model provider, MCP servers, package registries, and Git remotes each keep their own retention terms.

Can OpenCode run fully air-gapped?

OpenCode can run fully air-gapped only when the model, tools, and supporting services operate without external network access. Say local model inference when that is what you verified, and reserve air-gapped for a setup where the provider, tools, package installs, Git remotes, and telemetry have all been checked against the claim.

How do we enforce one configuration across a team?

Teams can enforce a shared OpenCode configuration using managed or MDM settings; checked-in project configuration provides shared defaults that developers may still override. OpenCode Enterprise sells one organization-wide enforcement path through its central config, including the option to allow only your internal gateway. Ask which config layer it ships through, because OpenCode's published precedence order makes remote organizational defaults overridable while managed and MDM settings are not.

Who owns the model bill?

Your organization pays the model provider or gateway account used by its OpenCode configuration; local inference instead uses your own hardware and operating budget. OpenCode Enterprise is priced per seat, with no published figure, and adds no token charge when you bring your own LLM gateway. Budget the model spend per team, because usage varies more than headcount does.

What should a pilot actually measure?

An OpenCode pilot should measure where requests went, what commands ran, and how much review each change needed. Speed claims are the easiest to gather and the least useful for a compliance decision; the data path and the command log are what a security review will ask about.