Enterprise features silently missing, or the admin says Community Edition
Enterprise is paid for, deployed, and the admin says Community Edition, or the features you bought are simply not there. The instance almost always cannot reach the licence server: corporate egress filtering, a forward proxy Strapi is not using, or a licence variable that never reached the container. Before you re-check the key in the dashboard, run one connectivity test from inside the running container, not from your laptop: can it reach license.strapi.io on 443. That single check separates the top cause from everything else.
00· Before anything
First: test connectivity from inside the container
The key looks fine in the dashboard, so nobody checks the one thing that usually explains this: whether the running instance can actually reach the licence server. Test it from inside the running container, not from a laptop that sits on a different network.
If the host is unreachable, you are on the top cause and nothing about the key itself is wrong. If it is reachable, confirm the licence variable is actually present in the process, not just in the manifest.
# from inside the running container, not your laptop
curl -sv https://license.strapi.io:443 2>&1 | head -n 20
# is the licence variable actually in the process?
printenv | grep -i licenThat one check is the whole diagnosis for most of these cases, and it is the check nobody does, because the key looks correct in the dashboard. Run it before you touch anything else.
Likely causes · The order I check them
Cause 01 of 01
The instance can't reach license.strapi.io
The admin shows Community Edition, or Enterprise features are absent, on an instance whose key is valid in the dashboard.
From inside the container, try to reach license.strapi.io on 443. Corporate egress filtering, or a forward proxy in the way, is the usual blocker.
Strapi validates the licence against license.strapi.io. If the instance cannot reach it, the licence check fails and the instance runs as Community.
The observable behaviour, a blocked host and an instance that shows as Community, is well supported. There is a folklore explanation that it falls back to an expiry date baked into the key; that mechanism appears in tickets but no source documents it, so state the behaviour, not the cause.
Allowlist the host by name, not by IP. The resolved IPs rotate, so an IP allowlist works once and fails later. If a forward proxy is in the path, point Strapi at it explicitly with proxy.fetch in config/server.
02
Allowlist license.strapi.io by hostname. IP allowlisting fails as the addresses rotate, and then fails again after you fix it the first time.
Likely causes · The order I check them
Cause 01 of 04
The licence variable isn't reaching the container
Connectivity is fine, and the instance still shows as Community.
Check the licence variable inside the running process, not in the Helm values, K8s secret or Cloud dashboard. printenv inside the container is the source of truth.
The variable is set in the manifest but not surfaced to the process: a Helm value that is not wired through, a secret in the wrong namespace, a Cloud variable set on the wrong environment.
Trace the variable from where it is defined to the running process and fix the break. Confirm with printenv inside the container, not by reading the manifest.
Cause 02 of 04
A forward proxy exists but Strapi isn't configured to use it
The host is only reachable through a corporate forward proxy, and Strapi is not going through it.
Strapi's HTTP layer does not inherit the host's proxy environment variables, so a proxy that works for curl on the same box does nothing for Strapi's licence check.
Set proxy.fetch in config/server.
The docs specifically attribute the licence check to proxy.fetch (used for licenses check, telemetry and webhooks), not proxy.global. proxy.global works too, but it is the broader setting; naming the right one is the difference between a precise fix and a scattergun one.
Cause 03 of 04
Admin served under a sub-path
Everything looks connected, and licence-limit endpoints 404 behind the reverse proxy.
When the admin is served under a sub-path, the licence-limit endpoints can 404 behind the reverse proxy if the path is not forwarded correctly.
Make sure the reverse proxy forwards the admin sub-path through to the licence-limit endpoints, or serve the admin at the root.
Cause 04 of 04
The key genuinely is wrong or expired
Connectivity is fine, the variable is present, and it still runs as Community.
Only after the causes above are ruled out: check the key value and its expiry directly.
Replace the key with a current one. This is last on the list deliberately: the key is the first thing people check and rarely the actual problem.
07
Where this is written down
The host allowlist and the connectivity requirement are documented in the Strapi support knowledge base, not on docs.strapi.io. That is citable and public, and it is worth saying plainly in a diagnosis: the thing that explains most of these cases is written down in the place people do not look. The proxy.fetch attribution is on the server configuration page. The expiry-fallback mechanism is not documented anywhere, so treat the blocked-host behaviour as observed and leave the mechanism out.
Common questions
Because the instance cannot reach the licence server. The dashboard shows the key is issued; it does not prove the running container can validate it. Test connectivity to license.strapi.io on 443 from inside the container.
No. The resolved IPs rotate, so an IP allowlist works once and breaks later. Allowlist the hostname instead.
Strapi's HTTP layer does not inherit the host's proxy environment variables. If a forward proxy is in the path, set proxy.fetch in config/server; that is the setting the licence check actually uses.
Diagnosed everything and still stuck?
S/01 — Performance & Architecture Rescue.
A fixed-scope week that finds the cause and fixes what's causing it.