Using your own infrastructure

The chart bundles everything the platform needs, so an install on hardware you own works with no external dependencies. On a cloud you probably already run managed equivalents — and would rather the platform used those than keep a database alive inside the cluster.

Every bundled dependency is optional. Each has an enabled flag and a documented external path, and nothing is duplicated in forked templates: the two postures differ in values only.

Bundled	Turn it off with	Replace it with
PostgreSQL (CloudNativePG)	cnpg.enabled: false	database.source
Redis	redis.enabled: false	secrets.managed.edisyl-redis
Object storage (MinIO)	minio.enabled: false	secrets.managed.edisyl-object-storage
Inngest	inngest.enabled: false	config.inngestBaseUrl + secrets.managed.edisyl-inngest

Where the chart can tell that a replacement is missing, it fails the render and names the value — a Helm error rather than a CrashLoopBackOff twenty minutes later. That covers the connection URLs and DATABASE_URL, but not every field: some keys render blank and surface at boot instead. Treat the checks as a safety net, not a specification.

PostgreSQL

database.source is the single switch for where DATABASE_URL comes from.

A connection secret you already have

cnpg:
  enabled: false

database:
  source: existing-secret
  existingSecret:
    name: my-postgres-connection
    key: uri

The credential never passes through values — the chart reads it from a Secret already in the release namespace. This is the better option where something else provisions your database, because nothing has to copy the password into a values file that ends up in git.

A connection string you supply

cnpg:
  enabled: false

database:
  source: managed

secrets:
  managed:
    edisyl-database:
      data:
        DATABASE_URL: "postgresql://user:password@host:5432/edisyl"

The render fails if that value is blank. Under secrets.provider: external-secrets the value comes from your store instead — see the values reference.

Your database still needs pgvector

Whatever you point at, the extension must be available — the first migration runs CREATE EXTENSION vector. Amazon RDS and Cloud SQL both offer it, but it is not enabled by default on either; check before you install.

The auth service keeps its own database

This is the part that catches people. The auth service does not share the application database, and the chart only provisions its database when the bundled cluster is running.

With cnpg.enabled: false the chart creates nothing. You provision that database yourself — a database, a role that owns it, and a Secret holding the connection URI — then point the chart at it:

edisyl:
  auth:
    database:
      secretName: my-auth-db-connection
      secretKey: uri

Setting edisyl.auth.database.create: true while cnpg.enabled is false fails the render, because there is no bundled cluster to create it in.

So does the LLM gateway

The same rule applies if you enable the bundled LLM gateway. Bifrost owns and migrates its own schema, and the chart never puts it in the application’s database. With cnpg.enabled: false, provision a database and a role for it and put the connection in a Secret — discrete keys, not a URI, because Bifrost has no DSN input:

bifrost:
  enabled: true
  database:
    source: existing-secret
    existingSecret:
      name: bifrost-db
      # The key names below are the defaults; change them only if your Secret
      # uses different ones.
      keys: { host: host, port: port, user: username, password: password, dbName: dbname }
    sslMode: require

bifrost.database.source: cnpg with cnpg.enabled: false fails the render, for the same reason the auth database does.

Redis

redis:
  enabled: false

secrets:
  managed:
    edisyl-redis:
      data:
        REDIS_URL: "rediss://user:password@host:6379"
        REDIS_HOST: "host"
        REDIS_PORT: "6379"
        REDIS_USER: "user"
        REDIS_PASSWORD: "password"
        REDIS_TLS: "true"

A URL on its own is not enough

The applications read the discrete fields at boot, not just the URL: REDIS_HOST, REDIS_PORT, REDIS_USER and REDIS_PASSWORD are all part of the schema, with REDIS_TLS optional and an empty password allowed. Supplying only REDIS_URL crash-loops the API on environment validation before it ever opens a connection.

The render only enforces the connection URLs. A missing REDIS_HOST is not caught at install time — it fails at boot. Set them all.

Two more Redis connections, and with bundled Redis off the first is required:

• secrets.managed.edisyl-redis-lattice → LATTICE_REDIS_URL. The render fails without it.
• secrets.managed.edisyl-redis-inngest → INNGEST_REDIS_URI, only when the bundled job runner is on.

ElastiCache and Memorystore both work. Use rediss:// and REDIS_TLS: "true" where the service requires TLS.

Object storage

minio:
  enabled: false

secrets:
  managed:
    edisyl-object-storage:
      data:
        OBJECT_STORAGE_PROVIDER: "s3"
        OBJECT_STORAGE_BUCKET: "my-edisyl-files"
        OBJECT_STORAGE_REGION: "us-east-1"
        OBJECT_STORAGE_ENDPOINT: ""
        OBJECT_STORAGE_FORCE_PATH_STYLE: ""
        OBJECT_STORAGE_ACCESS_KEY_ID: ""
        OBJECT_STORAGE_SECRET_ACCESS_KEY: ""

OBJECT_STORAGE_PROVIDER takes s3, s3compatible, or r2, and the distinction is load-bearing:

• s3 means real AWS S3. Leave ENDPOINT and FORCE_PATH_STYLE empty, set REGION and BUCKET, and either supply the two key values or leave them blank and use a pod IAM role.
• s3compatible is for MinIO, or any store reached through an explicit endpoint. It needs ENDPOINT set, and usually path-style addressing.

Choosing s3compatible while pointing at AWS — or s3 with an endpoint — is the silent misconfiguration to avoid: storage that looks wired up and writes nowhere.

Leave OBJECT_STORAGE_ACCESS_KEY_ID and OBJECT_STORAGE_SECRET_ACCESS_KEY blank to use a pod IAM role (IRSA on EKS, Workload Identity on GKE), which is the better option where your cluster supports it.

Query results need real S3

Saved query results are written through an AWS SDK client built with no endpoint override, so they only work against real S3 — not against the bundled MinIO, where every write fails on InvalidAccessKeyId. If your users save query results, external S3 is not just tidier, it is the working configuration.

Inngest

inngest:
  enabled: false

config:
  inngestBaseUrl: "https://api.inngest.com"

secrets:
  managed:
    edisyl-inngest:
      data:
        INNGEST_EVENT_KEY: "<event key>"
        INNGEST_SIGNING_KEY: "<signing key>"

Inngest Cloud has to reach your worker

The worker advertises itself to Inngest at http://worker:6002 — a cluster-internal address — and its ingress is off by default. A hosted Inngest cannot reach either, so it will never invoke a function.

Pointing at Inngest Cloud therefore also means exposing the worker on an address Inngest can call, through edisyl.worker.ingress, and overriding INNGEST_SERVE_ORIGIN in edisyl.worker.extraEnv to match. Plan that with us before you switch — it is the one external swap that changes your ingress surface.

Worth doing on a cloud for a reason beyond tidiness: the bundled job runner keeps its run history in an emptyDir, so completed runs and step results do not survive a pod restart. See Known limitations.

A worked example

Everything external, nothing bundled:

cnpg: { enabled: false }
redis: { enabled: false }
minio: { enabled: false }
inngest: { enabled: false }

database:
  source: existing-secret
  existingSecret: { name: my-postgres-connection, key: uri }

config:
  # Required whenever an app that reads it is enabled — the render fails
  # without it rather than handing an unreachable address to an OAuth client.
  apiPublicUrl: "https://api.example.com"
  domain: example.com
  inngestBaseUrl: "https://api.inngest.com"

edisyl:
  authSource: selfhosted
  auth:
    enabled: true
    database: { secretName: my-auth-db-connection, secretKey: uri }

secrets:
  provider: k8s-native
  managed:
    edisyl-redis:
      data:
        REDIS_URL: "rediss://user:password@host:6379"
        REDIS_HOST: "host"
        REDIS_PORT: "6379"
        REDIS_USER: "user"
        REDIS_PASSWORD: "password"
        REDIS_TLS: "true"
    edisyl-redis-lattice:
      data:
        LATTICE_REDIS_URL: "rediss://user:password@host:6379/1"
    edisyl-object-storage:
      data:
        OBJECT_STORAGE_PROVIDER: "s3"
        OBJECT_STORAGE_BUCKET: "my-edisyl-files"
        OBJECT_STORAGE_REGION: "us-east-1"
    edisyl-inngest:
      data:
        INNGEST_EVENT_KEY: "<event key>"
        INNGEST_SIGNING_KEY: "<signing key>"
    edisyl-auth:
      data:
        # SAML sign-in is on by default and GoTrue validates this key at boot,
        # so the render fails while it is blank. Turning SAML off instead means
        # enabling Google, since between them they are the whole set of
        # providers — a fleet with neither is one nobody can sign in to.
        GOTRUE_SAML_PRIVATE_KEY: "<saml private key>"

That runs the first-party services against your own datastores: no bundled database, cache, object store or job runner, and no CloudNativePG operator — that is only needed when cnpg.enabled is true.

Note it also enables the auth service, which is a deployment of its own rather than a bundled third-party chart. The application pods still mount small emptyDir volumes for scratch space; “nothing bundled” means no bundled infrastructure, not no volumes at all.

Keeping credentials out of values

Everything above puts credentials in a values file. For anything beyond a trial, use secrets.provider: external-secrets instead and let the chart read them from your secret manager — AWS Secrets Manager, Doppler, Vault or any other backend the External Secrets Operator supports. The chart then generates nothing, and every key must exist in the store up front. See Secrets and signing keys.