Rust · 0.1.0

Attachment storage

Choose where uploaded bytes live and include them in your backup plan.

Storage choices

Administrator storage settings support database, local filesystem and S3-compatible storage. Database storage keeps attachment bytes with database data; local storage needs a persistent directory; S3-compatible storage needs a reachable endpoint, bucket and appropriately restricted credentials. Upload-size settings affect what the application accepts, while proxies may impose another limit.

Validate before moving data

After configuring a destination, upload a small test file and read it back as its owner. Test the intended sharing behavior separately. A configuration change is not evidence that existing files were copied to the new destination. Preserve old objects until you have verified every needed attachment and your restore procedure.

Separate availability from access

The application checks attachment authorization before serving file content. Do not make a bucket public to fix an application permission error. Back up local files or object storage alongside the database, because the database can contain references without the underlying bytes.

Configure and verify a destination

Sign in as an instance administrator and open Settings → Storage. Select Local, Database or S3, review the upload-size setting, then save. For Local, keep the default template assets/{timestamp}_{uuid}_{filename} unless you have a reason to change it, and keep the data directory persistent. For Database, allow for larger database backups and buffered file reads. For S3, fill Access key ID, Secret access key, Endpoint, Region and Bucket; set path-style addressing only when your provider requires it. The form also requires a nonempty filepath template.

Use a two-file acceptance test

Before changing the default, download one existing attachment and retain it as a comparison. After saving, create a private test memo and attach a small uniquely named text file. Reload the memo and download that file; compare its contents with the original. Then download the older attachment again. A new file working while an old file fails points to a changed or removed old destination, not successful migration. Keep older storage definitions and objects until the needed files and restore path are verified.

Read the failure at the right layer

If Save is rejected, check required fields and whether STORAGE is deployment-managed. If upload fails, compare the file size with both proxy and instance limits, then check runtime directory permissions or S3 endpoint/credentials. If upload succeeds but download fails, inspect the actual object and memo authorization separately. Leaving a redacted credential field blank in an existing UI-managed configuration may preserve its secret; a deployment JSON file has different rules and an empty value really is empty.