# Which Problems Are Solved
The OTEL service.name resource attribute is hardcoded to "ZITADEL" in
setupOTelSDK, so the Instrumentation.ServiceName config and the
OTEL_SERVICE_NAME environment variable are both ignored. This makes it
impossible to distinguish between multiple Zitadel instances or
co-located services in tracing dashboards and alerting rules.
# How the Problems Are Solved
The hardcoded string is replaced with cfg.ServiceName so the configured
value flows through. An explicit check for the OTEL_SERVICE_NAME
environment variable is added at the top of resourceWithService, giving
it the highest priority per the OpenTelemetry specification.
# Additional Changes
None.
# Additional Context
Closes#11455
Backport to v4
# Which Problems Are Solved
The login v2 container has no way to verify upstream Zitadel API
connectivity before accepting traffic. The existing `/healthy` endpoint
always returns 200 regardless of whether the backend is reachable. This
means Kubernetes routes user traffic to pods that cannot actually serve
login requests, causing silent failures where the root layout swallows
gRPC errors and renders pages with default settings.
# How the Problems Are Solved
A new `/ui/v2/login/ready` endpoint creates a gRPC client using the same
auth and transport path as real requests, calls
`SettingsService.getGeneralSettings()`, and returns `200 OK` on success
or `503 Service unavailable` on failure. This verifies both network
connectivity and authentication credentials to the upstream Zitadel API.
Kubernetes supports readiness probes natively, so this endpoint can be
configured as a readiness probe to gate traffic until the login
container can connect to Zitadel. Docker Compose does not have a
readiness probe concept, so the compose healthcheck and
`healthcheck.mjs` default remain unchanged and continue using
`/healthy`.
The Docker HEALTHCHECK in the Dockerfile has been updated to use
`/ready` so that the image-level health status reflects actual upstream
connectivity. This will also allow us to simplify the Helm chart by
dropping the `wait4x` init containers that currently poll the Zitadel
API before starting the login pod, since the readiness probe makes them
redundant.
# Additional Changes
The `/ready` endpoint has been added to the OTEL HTTP instrumentation
ignore list to avoid noisy probe traces. Unit tests, a wiring spec
integration test, and an OTEL span filtering test have been added for
the new endpoint. The `# TODO: Check healthy, not ready` comment has
been removed from the Dockerfile. The `/healthy` endpoint is kept as-is
for liveness probes.
# Additional Context
The Helm chart changes to use `/ready` for readiness and startup probes
and to remove the `wait-for-zitadel` init container will be done in a
follow-up PR in the `zitadel-charts` repository.
# Which Problems Are Solved
The login container can only serve HTTP. In deployments where a reverse
proxy is not used, operators need the login container to terminate TLS
itself.
Closes#11473
# How the Problems Are Solved
The container now supports optional HTTPS via three environment
variables that match the pattern already used by the backend server:
`ZITADEL_TLS_ENABLED`, `ZITADEL_TLS_CERTPATH`, and
`ZITADEL_TLS_KEYPATH`. When `ZITADEL_TLS_ENABLED` is not set or set to
`false`, behavior is identical to before. When set to `true`, the server
reads the provided certificate and key files and serves HTTPS using the
lower-level `getRequestHandlers` API from Next.js.
The Docker healthcheck was updated to probe the correct scheme
automatically based on the same environment variable.
# Additional Changes
Added a dockerized integration test that verifies both HTTP and HTTPS
modes using testcontainers.
# Additional Context
The TLS path uses `getRequestHandlers` from
`next/dist/server/lib/start-server` instead of `startServer` because the
latter rejects self-signed certificates in production mode. This is the
same internal API that `startServer` itself calls.
---------
Co-authored-by: Copilot <[email protected]>
# Which Problems Are Solved
The React example needed updates to align with current best practices
and improve documentation clarity for developers integrating Zitadel
authentication.
# How the Problems Are Solved
Updated the React example codebase with improved authentication flow
using react-oidc-context, enhanced error handling and TypeScript type
safety, and refined component structure for better maintainability.
# Additional Changes
Updated documentation to reflect implementation details, added
comprehensive environment variable configuration examples with exact
variable names from the codebase, improved inline code comments, and
updated dependencies to latest stable versions.
# Additional Context
- Related to React integration example improvements
- Enhances developer experience when implementing Zitadel PKCE
authentication in React applications
<!--
Please inform yourself about the contribution guidelines on submitting a
PR here:
https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#submit-a-pull-request-pr.
Take note of how PR/commit titles should be written and replace the
template texts in the sections below. Don't remove any of the sections.
It is important that the commit history clearly shows what is changed
and why.
Important: By submitting a contribution you agree to the terms from our
Licensing Policy as described here:
https://github.com/zitadel/zitadel/blob/main/LICENSING.md#community-contributions.
-->
# Which Problems Are Solved
Replace this example text with a concise list of problems that this PR
solves.
For example:
- If the property XY is not given, the system crashes with a nil pointer
exception.
# How the Problems Are Solved
Replace this example text with a concise list of changes that this PR
introduces.
For example:
- Validates if property XY is given and throws an error if not
# Additional Changes
Replace this example text with a concise list of additional changes that
this PR introduces, that are not directly solving the initial problem
but are related.
For example:
- The docs explicitly describe that the property XY is mandatory
- Adds missing translations for validations.
# Additional Context
Replace this example with links to related issues, discussions, discord
threads, or other sources with more context.
Use the Closing #issue syntax for issues that are resolved with this PR.
- Closes #xxx
- Discussion #xxx
- Follow-up for PR #xxx
- https://discord.com/channels/xxx/xxx
# Which Problems Are Solved
The recently released NodeJS client libraries were missing
documentation, which made it difficult for developers to understand and
use the new features.
# How the Problems Are Solved
This pull request introduces the necessary documentation for the new
NodeJS client library, covering their installation and basic usage.
# Additional Changes
None.
# Additional Context
This documentation supports the recent client library release.
---------
Co-authored-by: Max Peintner <[email protected]>
# Which Problems Are Solved
- Broken or incorrect links on the "SDK Examples" introduction page. The
links to the new client libraries section all reference the "java"
section. This fixes it.
# How the Problems Are Solved
- Fixed the links to ensure they correctly point to the relevant
sections in the documentation.
# Additional Changes
None.
# Additional Context
None.
# Which Problems Are Solved
The recently released client libraries were missing documentation, which
made it difficult for developers to understand and use the new features.
# How the Problems Are Solved
This pull request introduces the necessary documentation for the new
client libraries, covering their installation and basic usage.
# Additional Changes
None.
# Additional Context
This documentation supports the recent client library release.
Mridang AgarwallaandGitHub
