Self-hosted license renewal: expiration warnings and post-expiry grace period

Last updated: October 8, 2026

Overview

Self-hosted LangSmith/LangGraph deployments validate their license key against LangChain's licensing service at startup and periodically afterward. When a license is close to expiring, the deployment shows a warning banner. This article covers why that warning can persist after a renewal and what happens if a license is allowed to expire.

Why the expiration warning can keep firing after renewal

When a contract is renewed, LangChain renews the old online keys in place. The expiration-warning banner only reflects the expiration date of whichever key is currently deployed in your environment.

The warning window itself is fixed at 7 days before expiry and isn't configurable today. There's no way to extend the lead time if your organization's change-control or procurement process needs more notice.

Resolution

If you get an expiration warning after you believe your license was renewed, confirm which key is actually deployed and compare its key ID and expiration date against the one the warning references. If your contract was renewed, LangChain renews the old online keys in place. If a new key was issued separately from the old one, deploy that key.

If you're unsure which key is current or which one is expiring, LangChain support can check LangChain's licensing records to confirm the valid replacement key and its expiration date.

What happens if a license actually expires

Deploy your renewal key before the expiry date and none of the below applies — the deployment continues running without interruption.

If a key does lapse, LangSmith and Agent Server behave differently, so it's worth knowing both:

LangSmith backend: The backend revalidates the license on a recurring check, roughly once a minute. Once the key's embedded expiry has passed, that check fails and the backend stops. There is no additional grace period here.

Agent Server: Already-running Agent Servers tolerate failed license checks for 24 hours from their last successful check — not from the expiry date. In practice this means the usable window after expiry is typically shorter than 24 hours.

The UI: The frontend process does not itself exit, so the UI may still load after expiry. Anything that depends on the backend will be unavailable.

Your data and deployments are not affected. Kubernetes deployment resources aren't deleted, and your data, projects, and configuration remain in place. Note that restarting a server won't recover the instance on its own — startup validation also requires a valid key — but deploying the renewed key brings everything back up.

References