Skip to main content
An installation that reports success is not the same as an installation that works. Three of the four milestones below fail silently — the pods stay Ready, Helm reports success, and nothing appears in any log. Check them in this order. Each depends on the one before it, so a failure at step 2 makes step 3 meaningless.

​
1. The Workloads

Every pod Running and ready. A CrashLoopBackOff here is the loud, easy case — the pod’s logs name the cause:
Then confirm the release itself:
The Data Plane release should be deployed. A release stuck in pending-upgrade means a previous run was interrupted.

​
2. The Licence

The deployment enrols with the Control Plane, receives a signed licence, and renews it automatically. Until that happens the platform runs on the enrolment latch and will eventually drop to read-only.
A deployment that cannot reach the Control Plane does not report an error. It enrols if the rules were open at install time, then goes quiet and reports itself healthy right up to the end of the grace period, because serving from a cached licence is normal operation rather than a failure.If the egress allowlist is in doubt, test it explicitly rather than waiting:
A licence has a 24-hour TTL and a 7-day grace period. Renewal happens automatically well before expiry, so a healthy deployment never approaches either.

​
3. File Serving

This is the milestone that most often fails silently, and the one worth checking before you let anyone use the platform.

​
The Ingress exists

You need a rootkey-minio-files entry with the same host as the platform frontend. If it is absent, rootkey_public_host was empty or rootkey_minio_ingress_enabled was off, and the Ingress was never rendered.

​
The workloads received the URL

It must print https://<your host>/files. If it prints the shipped example, the override did not apply — check that it is under global.envOverrides in your values file and not nested inside a workload.

​
The path reaches MinIO

A 403 or 404 from MinIO is the good result. It means the request reached object storage. If you get the platform’s HTML instead, the MinIO Ingress does not exist and the frontend is answering the request.

​
Objects are readable without credentials

A browser fetching an image sends no S3 credentials and never will. If the anonymous read policy was not applied, every avatar, logo and file link returns AccessDenied. The bucket job prints which it did:
Look for bucket ready: <name> (anonymous download enabled). If it says anonymous read NOT granted, re-run the MinIO chart — the policy is re-applied on every upgrade.

​
4. End to End

The only check that proves the whole chain. Nothing above substitutes for it.
1

Sign in

Open https://<your host> and sign in. On a single-tenant deployment the first user creates the organisation; everyone after that joins by invitation.
2

Upload a file

Upload any file through the interface. It should appear in the vault and, within a few seconds, show its blockchain anchor.A 500 on the first upload with nothing in the gateway log is the signature of a missing contract seed. Re-run it:
3

Open the file again

Click through to the file and open it. This is what proves the file-serving chain: the URL was built correctly, the Ingress routes it, and MinIO serves it without credentials.Check that the avatar and organisation logo render too — they travel the same path.
4

Verify the anchor

Open the file’s detail view and confirm the blockchain proof is present and verifiable. This proves the contract seed, the wallet, and the blockchain RPC endpoint are all working together.

​
Quick Reference

Everything above, as one block you can paste:
→ Next: Operations · Something wrong? Troubleshooting