Enterprise

opencode Enterprise provides organizational management features including remote configuration, managed settings enforcement, MDM deployment, compliance controls, and self-hosted infrastructure options.

Remote Configuration

Organizations can deploy default settings through a remote configuration file hosted at a well-known URL.

Setup

Place a configuration file at /.well-known/opencode on your organization's domain:

{
  "remoteConfig": {
    "url": "https://your-org.com/.well-known/opencode"
  }
}

openencode checks this location on startup and applies the remote configuration. Users can override remote settings locally, but managed settings (see below) take precedence.

Configuration Precedence

Settings are resolved in the following order (last wins):

Built-in defaults.
Remote configuration (.well-known/opencode).
Project-level configuration (opencode.json in the repository).
User-level configuration (~/.config/opencode/opencode.json).
Managed configuration (system-enforced, not user-overridable).
Environment variables.

Remote configuration is useful for:

Setting default providers and models.
Defining organizational coding standards.
Configuring permissions for MCP and other tools.
Enabling or disabling features across the organization.

Managed Configuration

Managed configuration is enforced at the system level and cannot be overridden by users. It is ideal for security and compliance requirements.

Configuration Locations

Managed config files are loaded from platform-specific directories:

Platform	Path
macOS	`/Library/Application Support/opencode/opencode.json`
Linux	`/etc/opencode/opencode.json`
Windows	`%ProgramData%\opencode\opencode.json`

Managed Config Example

{
  "managed": {
    "providers": {
      "allowed": ["opencode-zen", "github-copilot"],
      "blocked": ["openai", "anthropic"]
    },
    "permissions": {
      "mcp": {
        "database_*": "deny",
        "filesystem_write": "deny"
      }
    },
    "features": {
      "share": false,
      "telemetry": true
    },
    "compliance": {
      "instructions": "All code must comply with company security policies. Do not generate code containing hardcoded credentials, backdoors, or known vulnerable patterns."
    }
  }
}

Verification

To verify which managed settings are active:

opencode debug config

This command outputs the resolved configuration with annotations showing the source of each key:

Providers:
  allowed: opencode-zen (managed)
  blocked: openai (managed)
Permissions:
  mcp.database_*: deny (managed)
Features:
  share: false (managed)

Managed keys are clearly labeled so administrators can confirm their policies are applied.

MDM Deployment (macOS)

opencode supports macOS MDM (Mobile Device Management) deployment via configuration profiles.

Profile Structure

Create a .mobileconfig file with the ai.opencode.managed PayloadType:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key>
      <string>ai.opencode.managed</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>PayloadIdentifier</key>
      <string>com.your-org.opencode.managed</string>
      <key>PayloadUUID</key>
      <string>AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE</string>
      <key>PayloadDisplayName</key>
      <string>opencode Managed Settings</string>
      <key>PayloadDescription</key>
      <string>Managed configuration for opencode</string>
      <key>PayloadOrganization</key>
      <string>Your Organization</string>
      <key>managed</key>
      <dict>
        <key>providers</key>
        <dict>
          <key>allowed</key>
          <array>
            <string>opencode-zen</string>
          </array>
          <key>blocked</key>
          <array>
            <string>openai</string>
            <string>anthropic</string>
          </array>
        </dict>
        <key>features</key>
        <dict>
          <key>share</key>
          <false/>
        </dict>
      </dict>
    </dict>
  </array>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
  <key>PayloadIdentifier</key>
  <string>com.your-org.opencode</string>
  <key>PayloadUUID</key>
  <string>FFFFFFFF-GGGG-HHHH-IIII-JJJJJJJJJJJJ</string>
  <key>PayloadDisplayName</key>
  <string>opencode Enterprise Config</string>
  <key>PayloadDescription</key>
  <string>Enterprise configuration profile for opencode</string>
  <key>PayloadOrganization</key>
  <string>Your Organization</string>
</dict>
</plist>

Deploying with Jamf Pro

In Jamf Pro, navigate to Computers > Configuration Profiles.
Click New.
Select Custom as the payload type.
Upload the .mobileconfig file.
Scope the profile to the appropriate computers or groups.
Deploy.

Deploying with FleetDM

Add a configuration profile via the FleetDM API or UI.
Target the profile to macOS hosts.
FleetDM pushes the profile via MDM commands.

Verification on macOS

After MDM deployment, users can confirm the profile is active:

sudo profiles show | grep -A 10 "opencode"

The output shows the installed profile and its payload.

Compliance Controls

Provider Restrictions

Block unauthorized providers to ensure all AI interactions go through approved channels:

{
  "managed": {
    "providers": {
      "allowed": ["opencode-zen", "github-copilot"],
      "blocked": ["openai", "anthropic", "google-gemini"]
    }
  }
}

Permission Policies

Enforce granular control over what the AI model can do:

{
  "managed": {
    "permissions": {
      "mcp": {
        "database_write": "deny",
        "filesystem_write": "deny",
        "network_*": "ask"
      },
      "lsp": {
        "enabled": true
      }
    }
  }
}

Compliance Instructions

Inject organization-wide policies into every model interaction:

{
  "managed": {
    "compliance": {
      "instructions": "Do not generate code that uses deprecated libraries. Always include input validation. Never hardcode secrets or credentials. Follow the company style guide."
    }
  }
}

The share feature can be disabled for compliance with data loss prevention policies:

{
  "managed": {
    "features": {
      "share": false
    }
  }
}

When disabled, the /share command and any share-related UI elements are hidden or deactivated.

SSO Integration

Enterprise SSO can be configured through managed settings to enforce identity provider authentication:

{
  "managed": {
    "sso": {
      "provider": "oidc",
      "issuer": "https://your-org.okta.com",
      "clientId": "your-client-id",
      "scopes": ["openid", "profile", "email"]
    }
  }
}

Supported SSO providers include Okta, Azure AD, Google Workspace, and any OIDC-compatible identity provider.

Self-Hosted Infrastructure

Enterprise customers can deploy the opencode backend on their own infrastructure.

Requirements

Kubernetes cluster (EKS, AKS, GKE, or self-managed).
PostgreSQL 15+ database.
Object storage (S3-compatible).
At least 4 CPU cores and 16 GB RAM for the API server.

Deployment

A Helm chart is provided for Kubernetes deployments:

helm repo add opencode https://charts.opencode.ai
helm install opencode-enterprise opencode/opencode \
  --namespace opencode \
  --create-namespace \
  --values values.yaml

Configure values:

# values.yaml
replicaCount: 3
database:
  host: postgres.internal
  port: 5432
  name: opencode
  user: opencode
  password: "${DB_PASSWORD}"
storage:
  bucket: opencode-assets
  region: us-east-1
auth:
  sso:
    enabled: true
    provider: oidc
    issuer: https://your-org.okta.com
model:
  provider: opencode-zen

Troubleshooting

Managed Config Not Applied

Verify the config file exists at the correct path for your platform.
Check file permissions — the config must be readable by the opencode process.
Run opencode debug config to see whether managed settings are detected.

MDM Profile Not Deploying

Confirm the .mobileconfig is properly signed (if required by your MDM).
Check Jamf/FleetDM logs for profile installation errors.
Ensure the target devices are scoped correctly in the MDM.
Verify the PayloadType matches exactly: ai.opencode.managed.

Confirm the issuer URL is reachable from user machines.
Verify the client ID and scopes are correct.
Check that the callback URL is properly configured in the identity provider.

Security Considerations

Managed config files on disk should have restricted permissions (chmod 644 for readable, chmod 600 for files with secrets).
Self-hosted deployments should use TLS for all internal and external communication.
SSO client secrets must be stored securely, not in version control.
Regular audits of managed configuration ensure policies remain appropriate.
The compliance instructions system should be reviewed for any information leakage.

Remote Configuration​

Setup​

Configuration Precedence​

Managed Configuration​

Configuration Locations​

Managed Config Example​

Verification​

MDM Deployment (macOS)​

Profile Structure​

Deploying with Jamf Pro​

Deploying with FleetDM​

Verification on macOS​

Compliance Controls​

Provider Restrictions​

Permission Policies​

Compliance Instructions​

Disabling Share​

SSO Integration​

Self-Hosted Infrastructure​

Requirements​

Deployment​

Troubleshooting​

Managed Config Not Applied​

MDM Profile Not Deploying​

SSO Login Failures​

Security Considerations​