Schema-Registry-UI

Developers working with serialized messages may need to inspect a schema’s fields or see how its versions changed. Landoop’s Schema Registry UI provides a browser interface for those tasks against a separate Schema Registry server. It can expose management operations as well as read access, depending on configuration. The underlying registry owns the schema data and permissions, so hiding a button in the interface is not a substitute for enforcing access rules at that server.

Current guidance

This entry identifies Landoop/schema-registry-ui, a front end for inspecting and managing Avro schemas, subjects and versions. It is distinct from the registry server and from newer vendor consoles. Its README describes a browser application, optional proxying and configurable read-only or deletion controls; the evidence reviewed does not establish a current supported chart and registry-version combination.

A deployment needs to account for where requests originate. Direct browser access involves registry CORS policy, while a proxy becomes a separate trusted network boundary. Do not copy permissive wildcard CORS settings or expose a write-capable registry because the interface appears read-only. Enforce credentials and authorization at the service that owns schema data.

For replacement, list the operations users actually need: lookup, compatibility checks, registration, deletion and global configuration. Test those operations against a nonproduction registry, including denied actions and authentication failures. Preserve the underlying registry’s subjects, IDs and compatibility settings independently; replacing this UI should not require recreating schemas or changing the identifiers used by existing Kafka messages.