Docs

Support and issue reporting

Support starts after the docs. Requests without version, repro steps, and evidence will be returned for more information.

WindowsmacOSLinux
Support

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
Applies to
WindowsmacOSLinux
Covers
Support

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:

  1. App version from the About panel
  2. Operating system and version
  3. Whether the issue is in a release installer or a local source build
  4. Exact steps to reproduce
  5. Expected result
  6. Actual result
  7. Screenshot or screen recording for UI issues
  8. Relevant bucket, prefix, and object key information with secrets redacted
  9. 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.