Self-hosted Jedify on Google Cloud

A self-hosted installation runs the whole Jedify platform inside a Google Cloud project you own. OpenTofu (or Terraform) creates the cloud resources, two Helm charts install the platform services and the application, and a setup script configures sign-in against your own identity provider. No component uses a service-account key. Every workload authenticates as a Google service account through Workload Identity. The one stored credential is the Cloud SQL password: OpenTofu generates it, writes it straight into Secret Manager, and never prints it.

​

Architecture

Everything runs in one GKE Autopilot cluster, in two namespaces:

​

Google Cloud services

​

How requests reach the platform

One hostname serves the web app, the API, the MCP server and realtime. The Gateway routes by path: Zitadel is served on a second hostname of its own. Because the web app and the API share one origin, the browser’s calls from the web app to the API are same-origin requests. The Gateway is GKE’s own Gateway API implementation, so the installation ships no ingress proxy. By default it creates an internal regional load balancer, reachable only from inside your network. See DNS and TLS for the other choices.

​

How sign-in works

Zitadel is the identity layer built into the installation. It federates to your own OIDC identity provider (Okta, Microsoft Entra ID, Google and others), so your users sign in with their existing accounts.

1. A user opens the web app and is sent to Zitadel’s sign-in page, which only accepts users of your organization.
2. The user chooses your identity provider’s button and signs in there. Your provider redirects the browser back to Zitadel, and Zitadel completes the exchange with your provider from inside the cluster.
3. The first time a person signs in, Zitadel creates their user (or links them by email to a user that already exists). They see nothing in Jedify until you give them a role.
4. Zitadel issues a token to the web app. The API verifies it against Zitadel’s public keys and reads the user’s roles from Zitadel’s management API, inside the cluster.

The MCP server is a second sign-in client. AI agents and other MCP clients authorize through the MCP server’s OAuth endpoints on the application host, which hand off to Zitadel. See Identity and sign-in.

​

How model calls flow

The application never calls a model provider directly. Every model call goes to the LiteLLM proxy in the jedify namespace. The proxy runs as its own Google service account, which holds one role, roles/aiplatform.user, and calls Vertex AI over Private Google Access. The application asks for models by fixed names. The proxy maps each name to a Vertex AI model, so changing models is a values change, not an image change. You can also replace the bundled proxy with an OpenAI-compatible gateway you already run. See Model gateway.

​

Identities and permissions

OpenTofu creates three Google service accounts. Each Kubernetes ServiceAccount is bound to one of them through Workload Identity. Firestore has no per-database data role, so roles/datastore.user reaches every Firestore database in the project. That’s why the installation expects a project of its own.

​

Two roles

The install splits into two halves. One person or team can do both, but the split tells you which half to check when something fails. Role B can’t verify Role A’s half. Helm can check that a Secret Manager object has been named, never that it exists or holds the right keys. So each missing piece fails in a known way:

​

Release artifacts and versioning

Jedify publishes each release to a private release registry in Google Artifact Registry and grants read access to a Google identity you name. One release is six artifacts under one version: Versions are calendar versions: <year>.<month>.<release within the month>, with no leading zero (October 2026’s tenth release is 2026.10.10). A version names a set of charts and images tested together. It makes no compatibility promise, so read Upgrades before moving between versions, and always move every artifact to the same version. From 2026.10.2, every image is published for both arm64 and amd64. Releases 2026.10.1 and earlier publish Jedify’s own images for arm64 only.

​

What a self-hosted installation doesn’t support

• Context Graph Versioning. The git-backed version history of the Context Graph reaches its repositories through an Amazon S3 transport, which a Google Cloud installation doesn’t have. The rest of the application runs without it, and only that feature’s route returns an error, about a missing bucket name. See Context Graph Versioning.
• Sorting the semantic dimensions list by name. Firestore doesn’t support MongoDB collations, so that one sort returns an error. Every other sort works.

​

Next steps