Known Limitations

A candid list of what bnerd-keycloak-operator v0.1.0 does not cover yet. None of these are silent — where a limitation would otherwise cause surprising behaviour, the operator either rejects the configuration at validation or reports it via a condition.

No KeycloakProfile CRD

Unlike bnerd-gitlab-operator's GitlabProfile, there is no reusable defaults/topology CRD in v0.1 — the raw-resource engine has fewer knobs than gitlab-operator's chart-value composition, so per-instance spec fields cover the same ground today. This can be added later without breaking existing KeycloakInstance resources.

No dynamic watch on the managed Postgres cluster

Managed-Postgres readiness is observed via the PerconaPGCluster's generated credentials Secret plus a bounded 30-second requeue, not a live watch on the PerconaPGCluster object itself. In practice this means a managed Postgres cluster transitioning to ready is picked up within one requeue interval, not instantly.

Not covered in v0.1

• SMTP configuration — set spec.env directly for KC_SMTP_* if you need outbound mail integrated into a realm now; a first-class SMTP spec surface may follow.
• Backup/restore CRD — Postgres backups follow whatever backup policy your Percona PG Operator installation defines; the operator does not orchestrate Keycloak-specific backups.
• Realm/client lifecycle management — spec.realmImport covers a one-time import at startup; ongoing realm/client/role management is done through the Keycloak admin API or console, not through this CRD.
• NetworkPolicies / HorizontalPodAutoscaler — not rendered by the operator; apply your own alongside the KeycloakInstance if your platform requires them.

See the Changelog for what shipped in each release.