The support contract for serious users: what to read first, what evidence to include, and what gets sent back.
- What to read before contacting support
- Required evidence checklist
- Redaction rules
- How to write a useful bug report
Support and issue reporting
Read the docs before contacting support
Support is not a substitute for basic operator setup.
Before you contact support, you are expected to read the relevant documentation page for your issue:
- setup and validation issues: Quickstart and Profiles and connections
- object browser or transfer issues: Bucket browser and Transfers and sync
- security or vault questions: Security, vault, and licensing
- local build issues: Build, packaging, and release workflow
- first-line failure diagnosis: Troubleshooting
If your request does not cite the relevant doc page, expect a redirect back to documentation first.
Required evidence for every support request
Include all of the following:
- App version from the About panel
- Operating system and version
- Whether the issue is in a release installer or a local source build
- Exact steps to reproduce
- Expected result
- Actual result
- Screenshot or screen recording for UI issues
- Relevant bucket, prefix, and object key information with secrets redacted
- The docs page you followed before the issue diverged
Without that baseline, support cannot distinguish user setup problems from product defects.
Redact secrets properly
Never send:
- Secret Access Keys
- Cloudflare API tokens
- full presigned URLs with active signatures
You may send:
- bucket names
- object keys
- redacted URLs
- error messages with secrets removed
Good bug report format
Use this structure:
Version: 0.x.x
OS: Windows 11 / macOS / Linux distro
Install type: Release installer or source build
Docs referenced: /docs/troubleshooting
Steps:
1. ...
2. ...
3. ...
Expected:
...
Actual:
...
Artifacts:
- screenshot
- activity entry text
- transfer state summary
What gets sent back immediately
Expect a request for more information if your message only says things like:
- "it does not work"
- "upload is broken"
- "profile save failed"
That is not enough to debug a desktop storage client.
Feature request vs defect
Use support for:
- broken documented behavior
- regressions
- installer/runtime failures
- repeatable data-path issues
Do not frame these as defects unless documented behavior is wrong:
- features not yet shipped
- product scope outside the documented feature set
- commercial or licensing questions without version/context
The standard
If the issue is real, the docs are meant to let you prove it.
That is the standard this product is aiming for, and it is the standard support expects from incoming reports.