Try it: Nextcloud check — enter a domain, read the result. No account, no login, nothing stored.

Why from the outside?

The admin panel shows the version and the maintenance flag. What it does not show: whether /config/, /data/ or /.htaccess are reachable over the web, whether HSTS is missing, whether the instance still receives security updates. That is the perspective a scanner has — and the point where most self-hosted instances stand out.

What is checked

  • Version and support end: the version actually served, the branch, and the date until which security fixes ship. Compared against the official end-of-life data.
  • Exposed paths: config, data, .htaccess, .git and the Collabora app richdocumentscode. HTTP 404 is the expected answer. A 200 is a finding.
  • Security headers: HSTS, X-Content-Type-Options: nosniff, X-Frame-Options, Referrer-Policy.
  • Information leak: whether the server discloses its version.

What the result is not

Not a penetration test and not a vulnerability scan of the app. It is the first look: is this a supported version at all, and is something exposed that should not be. Both take seconds to answer, without occ and without SSH.

Example 

curl "https://your-domain.example/tools/api/nc.php?u=cloud.example.com"

It returns JSON: status, version, support end, and a list of checks marked ok, warn or bad. The same logic powers the three-language frontend.

If the version is old

The path is always the same: check the patch level, move to the latest patch of the running branch, then plan the major upgrade. Which branches still get support is in the table at /en/versions/nextcloud/.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.