Enable OpenWork Gateway

​

Deployment configuration and admin access

​

Prepare the deployment

1. Select matching, immutable release image tags for Den API, Den Web, and Gateway. Remove or reconcile component-specific image tags that would override the shared image.tag.
2. Initialize or migrate the database with a reviewed procedure, and verify the release schema before starting application traffic. A new empty database can use this release’s current-schema bootstrap; an existing database requires the upgrade procedure.
3. Precreate the database/authentication Secret in the release namespace using your secret manager. Den API and Gateway must use the same database and the same existing DEN_DB_ENCRYPTION_KEY; do not generate a new encryption key during an upgrade.
4. Configure the internal Gateway origin and a separate desktop-reachable Gateway origin, DNS, trusted certificates, and network access.
5. Render and inspect the values, deploy the matching images, verify the authenticated deployment contract, then verify Gateway access as an organization admin without an organization opt-in.

​

Helm values

image:
  tag: REPLACE_MATCHING_RELEASE_IMAGE_TAG
gateway:
  enabled: true
config:
  databaseMode: mysql
  internal:
    gatewayProxyBaseUrl: http://openwork-ee-inference:8791
    inferenceProxyBaseUrl: https://existing-models.example.com # Keep your existing Models endpoint.
  public:
    gatewayPublicBaseUrl: https://gateway.example.com
secret:
  create: false
  existingSecret: REPLACE_PRECREATED_DEN_SECRET
  keys:
    databaseUrl: DATABASE_URL
    betterAuthSecret: BETTER_AUTH_SECRET
    denDbEncryptionKey: DEN_DB_ENCRYPTION_KEY

​

Database and encryption references

​

Internal and public origins

• GATEWAY_PROXY_BASE_URL is the internal/service-to-service destination. Set it on Den API and Gateway. Internal HTTP is permitted across a trusted private boundary.
• GATEWAY_PUBLIC_BASE_URL is the desktop-reachable destination, not the internal Service address. Den API uses it in member Gateway provider configurations. Configure it on both services for shared startup validation.
• Models clients retain an explicit, valid desktop origin from INFERENCE_PROXY_BASE_URL; otherwise they use a valid GATEWAY_PUBLIC_BASE_URL. This selection is independent of GATEWAY_ENABLED: changing only management enablement does not replace a known public destination with the internal proxy. Preserve your existing Models HTTPS hostname even when Gateway management is disabled on the deployment. No subscription, key, or upstream-routing changes are required.
• Both must be explicit origins without credentials, non-root paths, queries, or fragments. A trailing / is allowed. Do not append /api/v1 to either value.
• Production public origins require HTTPS and a non-local qualified hostname or valid non-loopback IP address. Private DNS is possible, but member devices must resolve it, route to it, and trust its certificate. Internal .svc or .internal names are not valid production public origins.
• Helm validates production-style origins statically; startup validation does not check DNS, TLS, network reachability, or schema readiness. Local development exceptions require OPENWORK_DEV_MODE=1 and a non-production NODE_ENV, not a production workaround.

​

Canonical environment reference

​

Optional admin, webhook, and retention

gateway:
  enabled: true
  admin:
    enabled: true
  webhook:
    enabled: true
secret:
  create: false
  existingSecret: REPLACE_PRECREATED_DEN_SECRET
  keys:
    gatewayAdminToken: GATEWAY_ADMIN_TOKEN
    gatewayWebhookSecret: GATEWAY_WEBHOOK_SECRET

gateway:
  enabled: true
  retention:
    enabled: true
    adminTokenSecret: REPLACE_PRECREATED_RETENTION_SECRET
    adminTokenKey: GATEWAY_ADMIN_TOKEN

​

Sparse Helm compatibility

​

Open Gateway and retire old opt-in procedures

​

Google Vertex AI: each member signs in

​

Prepare Google Cloud and the OAuth app

1. In the inference project, enable the Vertex AI API and billing, arrange model quota, and confirm the selected model is available in the configured location. For Claude, enable the required partner-model access and accept its terms. A global endpoint is not a promise that every model supports it; verify each model/location combination.
2. Grant each member’s Google principal the required inference-project IAM permissions. roles/aiplatform.user is the documented broad role; a reviewed narrower role must include the prediction permissions needed by the model, such as aiplatform.endpoints.predict. OpenWork membership, model grants, Google consent, and Google IAM are separate checks. The Google email need not match the member’s OpenWork email; this mode does not enforce a Workspace-domain restriction by default.
3. Configure your organization’s Google OAuth consent screen and create an OAuth client with application type Web application, not Desktop app. Use an Internal audience when eligible; otherwise configure the appropriate External audience/test users and complete Google’s production/verification requirements. Your organization must satisfy Google’s authorized-domain policies for the callback deployment, including when using a hosted callback it does not own.
4. In Den AI Gateway > AI Providers > Add provider, choose the appropriate Vertex provider. In Key, select Each member signs in, enter the intended project and location, and supply the Web OAuth client ID and client secret. Review Models and Who can use it before saving; the form creates the upstream credential set and selected access rules together. Open the saved provider’s row to view its callback or edit Key. The secret is write-only; leave it blank for ordinary edits. Project/location are fixed on the provider: create a separate provider to change its destination.
5. Copy the exact callback URL displayed by Den into Google’s Authorized redirect URIs. The value is generated for this deployment and ends in /v1/inference-providers/oauth/callback; provider details expose it as oauthCallbackUrl. Do not substitute the Gateway inference origin, /gateway/connect, a desktop loopback URL, or another deployment’s hostname. Ensure Den’s canonical public API URL (DEN_API_PUBLIC_URL when explicitly configured), HTTPS reverse proxy, and browser session cookies agree with the displayed URL. Compare the complete URI, including any deployment path prefix, and do not add a trailing slash.
6. Confirm Who can use it includes only the intended members, teams, or organization. The form defaults to Everyone in the organization; turn it off and use Add person or Add team to restrict access. Saving links the chosen models and credential set through access rules. Creating a set through the API alone, being its creator, or being an administrator does not automatically grant inference access. Each granted member must still connect their own Google account.

• openid
• email
• https://www.googleapis.com/auth/cloud-platform

​

Member connection and browser account

1. Sign in to Den in that browser with the same OpenWork account that started Connect. A Desktop login does not automatically sign the external browser in. If the browser is using another OpenWork account, sign out there and use the initiating account; an entry link or OAuth state is not a substitute for that session.
2. Choose a Google account with IAM access to the configured inference project and approve the requested scopes. Google sign-in does not change the OpenWork member who owns the connection.
3. Return to OpenWork and refresh connection/model status as needed. Check the connected account and selected set before testing a model. Closing the browser or stopping the wait does not revoke a connection; use Disconnect to cancel pending sign-ins and remove the credential. If the attempt expires, start Connect again.

​

Session policy, rotation, and disconnect

• Google Cloud session-control policy can require interactive reauthentication (invalid_grant, including invalid_rapt). Revocation and token expiry can do the same. Use Reconnect when required; member OAuth does not guarantee indefinitely unattended operation or bypass organization policy. Use a separately approved workload-authentication mode for workloads that cannot pause for user sign-in; Gateway does not silently fall back to it.
• External OAuth apps in Testing generally issue refresh tokens that expire after seven days for this scope set. The identity-only exception does not apply because cloud-platform is requested. Complete the appropriate Google production process rather than weakening session policy. See Google’s token-expiration guidance and production-readiness guide.
• Rotating the OAuth client ID or client secret in a credential set cancels its pending sign-ins and revokes/erases its affected local Google credentials. Coordinate the Google-side change and Den update, then have affected members reconnect. Omitting the secret in an API edit preserves it; renaming alone does not revoke credentials. Changing credential mode or disabling the credential set also revokes its credentials. Re-enabling it does not restore erased tokens.
• Disabling the provider blocks inference and cancels pending sign-ins, but retains stored credentials; removing an access grant blocks that access without being a Google disconnect. These actions are not equivalent to revoking a Google grant. A current organization member can disconnect their retained credential even after grant loss or provider disablement; membership-offboarding cleanup handles removed members.
• Disconnect immediately marks the selected local member credential revoked, erases its token material, and cancels pending sign-ins. Remote Google revocation is best effort; a successful local disconnect does not prove Google completed revocation, and tokens are not retained for a later retry. If needed, remove the app’s access in the Google account directly. Refresh models in open Desktop/Web sessions; live Gateway authorization still prevents new requests from using the revoked credential.
• Google may revoke other connections sharing the same Google authorization grant, including another local set or the other Vertex provider using the same OAuth client. Do not assume separate local rows are independent Google grants. Disconnect does not delete your Google OAuth application. Gateway client keys and DEN_DB_ENCRYPTION_KEY are different credentials: rotating them is not a substitute for Google disconnect, and replacing the database encryption key is not an OAuth rotation procedure.

​

Verify before rollout

​

Verify and troubleshoot

{
  "deploymentCapabilities": { "version": 1, "aiGateway": true },
  "capabilities": { "gatewayDashboard": true }
}

This feature is not part of your deployment system, please ask an instance admin to configure deployment

Gateway management is not enabled on this deployment. Ask your administrator to configure GATEWAY_ENABLED=true.