Provider Testing

Provider testing verifies that the CLI can construct the configured MeshKit provider and run health checks against it.

Use this before changing environments, updating provider credentials, documenting support for a provider, or collecting release evidence. A passing provider test is useful evidence, but it is not the whole production-readiness story.

What To Validate

For production storage, MeshKit needs both:

• Encrypted byte storage through the selected provider.
• MeshKit metadata support for proofs, capsules, mailboxes, sync records, policies, or other workflows you depend on.

Raw IPFS reachability is not enough for MeshKit production claims.

Local Provider Check

npx -p @meshkit/cli meshkit providers test --json

With the default local-dev setup, this proves only that the local provider can run the doctor path.

Live IPFS HTTP Profile

Example meshkit.config.json:

{
  "version": 1,
  "appId": "my_app",
  "provider": {
    "type": "ipfs-http",
    "ipfsApiUrl": "https://ipfs-api.example.com",
    "metadataApiUrl": "https://meshkit-metadata.example.com",
    "tokenEnv": "MESHKIT_PROVIDER_TOKEN",
    "timeoutMs": 15000,
    "retries": 2
  }
}

Run:

MESHKIT_PROVIDER_TOKEN=redacted \
npx -p @meshkit/cli meshkit providers test --config meshkit.config.json --json

The token value belongs in the environment or secret manager, not in the committed config file.

Shortcut Environment Profile

For one-off checks, the CLI can build an HTTP IPFS provider from environment variables:

MESHKIT_IPFS_API=https://ipfs-api.example.com \
MESHKIT_METADATA_API=https://meshkit-metadata.example.com \
MESHKIT_PROVIDER_TOKEN=redacted \
npx -p @meshkit/cli meshkit providers test --json

Use a config file for repeatable releases. Use environment shortcuts for local diagnosis.

Evidence To Capture

For release notes or provider support claims, capture:

• Command and package version.
• Redacted config shape, including provider type and endpoint names.
• JSON output from meshkit providers test --json.
• A sample encrypted write and proof inspection when the provider supports storage.
• Cleanup behavior for any remote objects written during validation.

Do not capture:

• Bearer tokens.
• Private keys or exported identity secrets.
• Plaintext payloads.
• Full retrieved bytes unless the artifact store is approved for that data.

Common Misreads

Failure Triage

Next Steps

• Use Production setup before promoting a provider.
• Use Live validation to decide what evidence belongs in release artifacts.
• Use CLI troubleshooting for symptom-level fixes.