Patchman
Separate organisation, client access and physical placement
Dowe uses three distinct concepts. Folders organise a person’s library. Logical buckets define the customer-facing storage scope and its policies. Physical provider records describe operator-managed buckets in MinIO, Cloudflare R2, AWS S3 or Google Cloud Storage. These records solve different problems and should not be treated as interchangeable names for the same bucket.
Every stored file belongs to a logical Dowe bucket and records the physical provider chosen when the file was written. The logical bucket does not choose or inherit a provider. Two files in one logical bucket can therefore have different physical assignments without changing the endpoint or credentials the customer uses.
Ordinary library uploads receive a private default logical bucket. Developer uploads and ordinary library files use one canonical file registry rather than separate object catalogues. A folder has no physical object and no provider assignment. This keeps organisation metadata from accidentally becoming a storage-placement instruction.
Follow one file from upload to later read
Before an upload writes bytes, Dowe reserves capacity against an eligible provider. The file record then binds the logical bucket, physical provider, object identity and stored metadata. The original and any generated preview are accounted for as stored content rather than assuming a thumbnail costs no space.
A later read resolves the file’s existing assignment. Changing provider priority or activating another provider changes future placement; it does not move old files. Deactivating a provider prevents new placement while existing assignments remain available for reads and deletion through that provider.
The customer continues to use Dowe’s endpoint. Provider credentials stay on the server and are not returned by ordinary file or bucket APIs. A public share is served through Dowe’s authorised delivery path instead of handing the customer a physical bucket login.
Understand priority tiers and strict capacity reservations
The default order is MinIO, then R2, then S3, then GCS. Administrators can edit priority. Dowe selects the first priority tier containing an active, reconciled provider with enough available capacity, then rotates among eligible provider rows in that tier. Multiple rows can use the same provider type.
A provider’s total size is a strict byte ceiling. Available capacity is total size minus stored bytes and outstanding reservations. Dowe reserves before network transfer so concurrent uploads cannot each assume the same remaining space. Database locks are released before the transfer; a durable reservation records the work that must later be finalised or recovered.
Uncertain writes and failed deletions remain accounted for until recovery confirms their outcome. A timeout does not establish that the remote object was never written. Reducing capacity below used plus reserved bytes is rejected. If no eligible provider has space, the upload fails rather than silently exceeding the ceiling or inventing a new placement.
Keep provider administration separate from customer credentials
Administrators register a physical bucket, endpoint, region, priority, capacity and provider-specific credentials. Stored credentials are encrypted with a server-held root and purpose/version separation. Provider lists conceal the secret material. An authorised credential reveal is a separate audited action, and rotation records a new credential version.
Registering credentials alone does not make an existing bucket safe for placement. Inventory reconciliation and confirmation of exclusive Dowe writes are required before activation. Strict capacity accounting assumes another service is not writing objects behind Dowe’s back. An operator must investigate and reconcile unexpected inventory before accepting more uploads.
A populated or active provider cannot simply change its physical bucket, endpoint, region or provider type. Such a change would make existing file assignments point somewhere else. Add another provider for new capacity and retain the existing record for the files already stored there. Rotating credentials is a supported maintenance action and is different from retargeting a provider.
Configure a client with Dowe’s endpoint and logical bucket
Create the logical developer bucket in Dowe and use the endpoint and region shown by the Storage console. The S3-compatible route is path-style: the Dowe endpoint is followed by the logical bucket name and object key. Do not replace it with a physical R2 or S3 endpoint; that bypasses the registry, permissions and placement model.
Issue a Dowe key for the intended bucket and choose only the read, write and delete permissions the client needs. Add a prefix when a client should operate within one key namespace and an expiry when access should be time-bound. Capture the issued secret securely at creation and keep it out of source control, frontend bundles and shared URLs.
Dowe accepts its scoped Bearer API token or supported AWS Signature Version 4 requests. Use one authentication method for a request. A presigned URL carries its own limited authorisation and should be treated as a secret while valid. Its lifetime remains bounded by the bucket policy; it does not become a provider credential.
Distinguish authentication, prefix scope and browser CORS
Each request validates that the key is active, not expired or revoked, and belongs to the requested bucket and owner. The method must have the matching permission. A prefix-scoped key may access only matching object keys or listing prefixes. A shared Patchman browser session does not authorise an arbitrary external storage client.
CORS controls whether an approved browser origin can make the relevant cross-origin request. It does not replace authentication or grant a public right to a private object. Configure origins, methods, headers and exposed response headers for the actual browser client; server-to-server clients still need credentials even though browser CORS does not apply to them.
Logical bucket policy also covers allowed MIME types, maximum object size, overwrite permission, signing lifetime and tags. Overwrite protection and conditional writes can prevent an unintended replacement. Check the returned error rather than repeatedly retrying a request whose type, prefix or overwrite policy is forbidden.
Test the operations your client actually uses
S3-compatible does not mean every AWS S3 feature is implemented. Dowe supports the object and listing operations exposed by its endpoint, with explicit failures for unsupported options. Clients that assume multipart upload, object copying, ACLs, object lock or arbitrary storage-class headers need a compatibility review before use.
Start with a small object: write it, read it back, compare its bytes, inspect the ETag, list it within the allowed prefix and delete it only if the key is meant to have deletion rights. Test a denied prefix and an unauthorised method as well as the happy path. Configure the SDK to use the console’s endpoint and region, path-style requests and only supported options.
Keep the reported maximum upload size in view. The deployment host and proxy may impose a stricter request limit than the physical provider. More provider capacity does not automatically increase the request body a web server can accept. Use a suitable deployment topology for the intended file sizes rather than bypassing Dowe to upload directly into a physical bucket.
Plan recovery beyond a successful object write
A recoverable Dowe service needs the file registry, logical bucket and access metadata, provider configuration, encrypted credentials and the server-held encryption root as well as the physical objects. A bucket inventory alone cannot reconstruct private ownership and published-board context. A database backup without the objects cannot deliver the files.
Back up those parts through controlled independent processes and test a restoration. Confirm that restored file assignments resolve the expected object, that private ownership remains enforced and that expired or revoked credentials stay invalid. Do not treat a successful upload or a healthy provider connection test as proof that recovery works.
For an uncertain upload or deletion, retain its reservation and safe reference until the maintenance process confirms what exists remotely. Avoid manually clearing accounting rows to make the dashboard appear to have free space. Investigate the durable operation and reconcile inventory through the administrative workflow.
Continue from architecture to a reviewed delivery
Use files, folders and boards for everyday organisation and sharing and access for recipient delivery. Follow the first-file walkthrough before expanding an integration, and open Dowe to inspect the endpoint and policy for your own logical bucket.