Temporal stores workflow state and exposes operational tooling for workers and developers. The UI can show workflow histories, task queue behavior, schedules, and namespace-level controls. A public match for a Temporal-branded page may be a self-hosted UI, a cloud login, a documentation site, or an unrelated page using the word. The product count is useful only after the owner maps the namespace boundary.
A count-only ZoomEye measurement on 2026-10-29 returned 2,086 matches for title="Temporal" and 197 for app="Temporal". Both used sub_type=all, page 1, and page size 1. The title result is larger and selected for discovery. It is also broad because "Temporal" can describe concepts and content unrelated to the Temporal service. The count is not a list of exposed workflow clusters.
Find the deployment model first
Temporal Cloud supports account roles and namespace-level permissions. Its self-hosted production checklist notes that the self-hosted service does not provide RBAC or audit logging out of the box. Teams can develop their own control plane or put the service behind an identity-aware gateway. That difference matters: a cloud namespace setting and a self-hosted mTLS configuration are not interchangeable controls.
For a candidate owned by the organization, determine whether it is cloud or self-hosted. Inspect the TLS certificate and DNS record, then compare the hostname with deployment inventory. Do not send a login attempt to an unknown system. If the service is self-hosted, review the network path to the UI, the gRPC frontend, the history service, and the database. The UI is one endpoint, but workflow authority may be spread across several components.
Namespace isolation deserves a direct test. A user or service account should only see namespaces granted by policy. A worker configured with a namespace should not be able to poll a different tenant's task queue. A token or certificate used by one namespace should not authorize an administrative action in another. Test both the UI and the API, because a UI route that hides a button does not necessarily change the underlying permission.
Keep workflow data inside its tenant
Workflow histories can contain business data, credentials passed through arguments, and operational metadata. A broad read role can reveal more than a dashboard suggests. Review payload encryption and codec-server behavior when sensitive data leaves the service boundary. A codec server is not a substitute for namespace authorization; it adds another service that must also be protected.
Search and visibility settings should be configured per namespace and reviewed after an upgrade. An operator may need global visibility for incidents, but that should be a deliberate role with logging. Avoid a shared admin token in worker images, CI systems, and developer laptops. Create separate service identities with the smallest namespace and operation scope.
The title count of 2,086 suggests that a product-name query alone is not enough. Validate a candidate by checking a known UI path, certificate, response header, or asset, then compare it to the deployment record. A strong product fingerprint gives a smaller starting set, but it still does not prove that authentication is weak.
Use discovery to improve ownership
Create a table with endpoint, deployment model, namespace, owner, authentication method, and last authorization test. Include the ZoomEye query and time so a later analyst can reproduce the candidate set. For a cloud deployment, confirm the account and namespace role assignments. For self-hosted, document the gateway, TLS, identity provider, and audit source that wrap the service.
If a workflow endpoint is reachable from a network that should not have access, close the route before adding more monitoring. If it is intentionally public, test anonymous access and a low-privilege user against multiple namespaces. A login page that appears healthy does not show whether an API key can read histories or start workflows.
Temporal discovery is most useful when it leads to a namespace-by-namespace authorization review. The count identifies candidates. Workflow control, history confidentiality, and tenant separation determine whether the deployment is actually scoped.