Keeping models in your own storage

A workspace can be created in storage your office runs: an S3-compatible bucket on Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO or anything else that speaks the protocol. Every file is written to it and read from it by the add-in on your own Windows machines, with a credential your tooling puts there. Syncture holds the bucket's address and never the credential, and keeps the names, versions, locks and shares that make the workspace work. This is how the bucket and the credential are set up.

What stays with Syncture

Everything but the files.

Names and versions: Workspace, folder and model names, every version with who published it and when, and the list of pieces each version is made of, by digest. Without these the bucket is bytes with no order.
Locks and ownership: The write lease on each model, the per-file claims, and the element-ownership ledger the add-in exchanges between machines while people work. A ledger too large for its row is written to Syncture's own regional store: element identities, never a file's contents.
Shares and groups: Who may reach what, resolved on every request as in every kind of workspace. A share lets somebody see the names; their machines still need a credential for the bucket before a file moves.
Deleting: Deleting a model removes its rows at once and queues the pieces no version names any more. A machine signed into the workspace whose credential may delete removes them from the bucket, one object at a time, and the console shows what is waiting. Deleting the workspace removes Syncture's records and leaves its prefix in your bucket for your own tool to remove.

The bucket

Any store that speaks the S3 protocol with Signature Version 4, over HTTPS. The console asks for its address: provider, endpoint, bucket, signing region, an optional prefix, and how the bucket is addressed.

Amazon S3: The regional endpoint of the bucket. Server-side encryption, Object Lock and replication are yours to set on the bucket. Endpoint https://s3.eu-central-1.amazonaws.com. The bucket's region, as the endpoint names it: eu-central-1. Virtual-host addressing.
Cloudflare R2: The S3 endpoint of your Cloudflare account, with the bucket in the path. An EU-jurisdiction bucket stays in the EU. Endpoint https://<account-id>.r2.cloudflarestorage.com. R2 signs every request for the region auto. Path-style addressing.
Backblaze B2: The S3-compatible endpoint shown on the bucket, and an application key restricted to that bucket. Endpoint https://s3.eu-central-003.backblazeb2.com. The region in the endpoint: eu-central-003. Virtual-host addressing.
Wasabi: The regional service URL of the bucket. Endpoint https://s3.eu-central-1.wasabisys.com. The region in the endpoint: eu-central-1. Virtual-host addressing.
MinIO: Your own server, over HTTPS. Path-style addressing, which is MinIO's default. Endpoint https://minio.example.com. What the server is configured with; us-east-1 unless you changed it. Path-style addressing.

Anything else that speaks the protocol is Other S3-compatible in the console, with every field typed by hand. Two workspaces may share a bucket: each keeps its objects under its own prefix, <prefix>w/<workspace>/, which the console shows and which is what you remove when a workspace is gone.

The credential

A key pair for the bucket, scoped to the workspace's prefix, deployed by you.

What it may do: Put, get and delete objects under the workspace's prefix, and nothing else: s3:PutObject, s3:GetObject and s3:DeleteObject on <bucket>/<prefix>w/*. Listing the bucket is not needed. The handbook carries the policy document for each provider, ready to paste.
Without delete: A credential that may put and get publishes and opens models. It never removes the pieces Syncture stops naming, so give delete to the machines you want tidying up, such as a BIM manager's, and the console shows what is waiting.
One per office: One credential for every workspace in the bucket is the ordinary deployment, like one key for every encrypted workspace. One per machine works the same way and costs you the rotation.
Rotating it: Every location below holds a list. Add the new profile beside the old one, prove it across the estate, then remove the old one. Overwriting in a single edit takes every machine dark at the next policy refresh.

Where a machine looks

Four places, in this order. The first profile whose endpoint and bucket match the workspace wins.

Every user of a machine: HKLM\SOFTWARE\Policies\Syncture\Storage\<name>: one key per profile, holding the values Endpoint, Bucket, Region, AccessKeyId and SecretAccessKey, and Prefix and PathStyle when they differ from the workspace's. What Group Policy and Intune write, and the first place looked at.
A deployment package: Any *.storage file under C:\ProgramData\Syncture\Config\Storage\, UTF-8, one [section] per profile with a line per value. Lines beginning # are notes.
One signed-in user: The same keys under HKCU\Software\Syncture\Storage\<name>, or any *.storage file in %APPDATA%\Syncture\Storage\. For one architect on one laptop.
A vault you already run: Either registry key's StorageFile value, holding a path to a file or a folder of them. Your tooling writes a file and Syncture reads a file, with no integration either way.

Nowhere else. There is no environment variable, no hidden location and no fallback through Syncture, and reading any of them needs no administrator rights, because the add-in runs as the user. Syncture never writes a credential anywhere: it reads what you deployed.

[acme-models]: The profile's name, which is only a label. One section per profile.
endpoint: The HTTPS address of the storage, exactly as the workspace names it.
bucket: The bucket, exactly as the workspace names it. These two are what a profile is matched by.
region: The signing region: eu-central-1, auto for R2, us-east-1 for a MinIO left at its default.
access_key_id: The key pair's id.
secret_access_key: Its secret. Never printed by any Syncture command, and never sent anywhere but the bucket.

Optional lines: prefix and path_style, for a profile that has to differ from what the workspace says. A profile and a workspace key may sit in the same deployment package; they are read from separate places and never confused.

Putting it there

On one machine, with the installer, in PowerShell run as administrator.

.\Syncture-Setup.exe --storage set --name acme-models --endpoint https://s3.eu-central-1.amazonaws.com --bucket acme-models --region eu-central-1 --access-key-id AKIA… --secret-access-key … --machine | Out-Host

The installer is the file you download from us. It writes one profile file for every user of the computer, with permissions only administrators may change, and adds to what is there. Across an estate, whatever you already run writes one of the four locations: a Group Policy preference, an Intune Win32 app, an RMM package, or a scheduled task filling a StorageFile path from your vault. The exact click paths, fields and permissions, and the policy document for each provider, are in the handbook, which is written to be forwarded whole. A workspace key travels the same roads.

.\Syncture-Setup.exe --storage check | Out-Host

One line per location, with each profile's name, endpoint and bucket, or the reason a line is not a profile, and never a secret. It exits non-zero when a location holds something that is not a profile, which is what an RMM reads as a compliance check.

.\Syncture-Setup.exe --storage probe --bucket acme-models | Out-Host

Writes one small object under the bucket's probe prefix with the profile found on this machine, reads it back and deletes it, and prints what each step answered. The same probe the add-in runs when it first opens the workspace, whose result the console shows as the last check.

Three rules

Deploy before anybody publishes

A workspace with no credential on any machine costs nothing. A model published from the one machine that has one, and opened from a machine that does not, is a sentence in the add-in naming the bucket and the place it looked. The kind is chosen when the workspace is made and cannot be changed afterwards, like a key.

The bucket's durability is yours

Syncture keeps the names and the list of pieces each version needs, and can say which object a version is missing. It cannot restore one. Versioning, replication, retention and backup are the bucket's settings, and they are yours to make.

Nothing of the bucket reaches Syncture

No route of the service accepts a credential, and a request carrying one is refused. The service holds the bucket's address, which the console shows and a ticket may quote, and the add-in on your machines does every read and write.