Persistent storage & object storage

Every deploy replaces your app's container with a fresh copy. That's what makes deploys safe to repeat, and it's also why a file your app wrote yesterday is gone today unless you tell Synq to keep it. This page covers two ways to do that: persistent storage for paths on the server, and object storage for a bucket that lives outside your app altogether.

Where it is

Open the project and choose Storage in the project menu. For a single app it shows, from top to bottom: Volumes, Persistent storage, File mounts and Object storage. The same cards (except Volumes) are also on the Configuration tab.

For a compose or monorepo project, volumes are set per service. The Storage section shows the Volumes manager and a Volumes are set per service card whose button opens Apps & Services; each service has its own Volumes tab.

Persistent storage (paths that survive a deploy)

Synq already knows what some frameworks write. A Laravel app keeps storage/ with no configuration at all, because that's where Laravel puts uploads, sessions, cache and its logs.

storage
public/uploads

uploads:/app/public/uploads
/srv/app-data:/app/var

To go back to the framework's own list, press Use framework defaults. To keep nothing at all, save an empty list: that's a real choice, and Synq won't quietly add the defaults back.

You can declare the same thing in your repository, so a fresh deploy of the same code gets it automatically:

{
  "volumes": ["storage", "uploads:/app/public/uploads"]
}

Things worth knowing

• The first deploy seeds the folder. Whatever your app ships at that path (Laravel's storage/ skeleton, for instance) is copied in, so the app doesn't start against an empty folder.
• Later releases don't refresh it. That's the point: it's your data now, not the image's. So don't list a path that also contains code. Laravel's database/ folder holds migrations as well as the SQLite file, which is why Synq keeps storage/ and not database/.
• Volume names are scoped per project. Two projects that both keep storage never share one volume. The named volumes these paths create also appear in the Volumes manager, where you can back them up. A folder on the server (/srv/app-data:/app/var) is a plain bind mount and isn't listed there.
• One copy per server. A path lives on one server's disk. Two copies of the app on different servers each see their own folder; use object storage for shared uploads.

Object storage (an S3 bucket)

A path on the server stops data loss, but it doesn't scale: run two copies of your app and each one gets its own uploads folder, which shows up as files that exist for some visitors and 404 for others. A bucket is shared by every copy and outlives the server.

Synq connects a bucket using your framework's own variable names, so you don't have to hunt for them. A Laravel app gets FILESYSTEM_DISK=s3 plus the AWS_* variables its S3 disk reads; a Django app gets the AWS_STORAGE_BUCKET_NAME / AWS_S3_* names django-storages reads; anything else gets neutral S3_* names.

The card then shows the bucket, the provider and exactly which Variables were set. Disconnect removes those variables again: only the ones the connection added, never anything you set by hand.

Using the bucket from your code

Once connected, your framework's normal file API writes to the bucket: Storage::put(...) in Laravel, default_storage in Django. For other stacks, read the S3_* variables the card lists and hand them to your S3 client.

Related guides