Create the project and bucket

The first stage on the Google Cloud side, all in the Google Cloud Console. By the end you will have a bucket and the region code it lives in.

1. Create a Google Cloud account and project

Skip this if you already have a project you want to use.

1. Go to https://console.cloud.google.com/ and sign in with a Google account (personal Gmail or Workspace).
2. First-time users get a $300 free credit for 90 days. Accept the billing terms and add a credit card. You will not be charged unless you exceed the credit or actively upgrade.
3. Once signed in, click the project dropdown at the very top of the console, next to “Google Cloud”, and click New Project.
   • Project name - sliick-files (or similar). The name is human-readable.
   • Project ID - autogenerated, for example sliick-files-481203. This is the globally unique ID Google Cloud uses internally. Write it down.
   • Organization - leave at default, or pick your Workspace org.
4. Click Create. Wait about 30 seconds, then make sure the project dropdown shows the new project. Everything below assumes you are inside it.

2. Enable the Cloud Storage API and link billing

1. In the console search bar at the top, type Cloud Storage and open the service.
2. If you see a prompt to Enable the Cloud Storage API, click it.
3. If you are prompted to link a billing account, do so. Cloud Storage is a paid service even though usage may fall entirely under the $300 free credit.

3. Pick a region

Every bucket lives in a single location. Pick the one closest to your Salesforce org and users. Common choices:

Region code	Location
us-central1	Iowa (default)
us-east1	South Carolina
us-west1	Oregon
europe-west1	Belgium
europe-west3	Frankfurt
asia-southeast1	Singapore

Write down the exact region code. The region in Sliick Settings must match the bucket’s location exactly or every signed request will fail.

Multi-region and dual-region buckets sign differently. The value you enter is the location name in lowercase, not a specific region code. For a multi-region bucket enter us, eu or asia; for a dual-region bucket enter the dual-region name, such as nam4 or eur4. A specific region code like us-central1 will not match a multi-region US bucket, and the connection test fails with a signature error.

4. Create the bucket

1. In Cloud Storage → Buckets, click Create.
2. Name your bucket - must be globally unique across all of Google Cloud. Use something like sliick-files-acme-prod (lowercase, hyphens, no underscores). Write the exact name down.
3. Choose where to store your data - Region, then pick the region code from the previous step. Multi-region and dual-region cost more and are not required.
4. Choose a default storage class - Standard. Other classes (Nearline, Coldline, Archive) have per-access fees that do not fit an active file workload.
5. Choose how to control access to objects:
   • Prevent public access - leave On (recommended). Sliick uses presigned URLs; the bucket should never be publicly listed.
   • Access control - Uniform (recommended). Fine-grained ACLs add complexity Sliick does not need.
6. Choose how to protect object data - leave the defaults here. You turn Object Versioning on in the next step instead, from the command line.
7. Click Create.
8. If a popup warns about public access prevention, confirm Enforce public access prevention on this bucket.

5. Turn on Object Versioning, so deletes are restorable

Deleting a file in Sliick removes the object from the bucket immediately. With Object Versioning on, the deleted object is kept as an archived generation and the file stays restorable from Sliick Files Setup → Deleted Files for up to 100 days. Without it, deletes are permanent and the Restore action tells you to enable it.

gsutil versioning set on gs://YOUR_BUCKET

This is separate from Sliick’s own version history, which works either way.

6. Add two lifecycle rules

Both stop storage cost accumulating invisibly. Add them under the bucket’s Lifecycle tab, or with gcloud storage buckets update.

Rule	What it does
Delete noncurrent versions after 100 days	With Object Versioning on, every deleted object leaves an archived generation behind. 100 days matches Sliick’s own Deleted Files retention, after which the file is no longer recoverable through the UI anyway
AbortIncompleteMultipartUpload after 2 days	Large-file transfers stream in parts. If a transfer is interrupted and the cleanup call also fails, the parts linger invisibly and accrue cost. Sliick logs the leak, but clearing it is the bucket’s job

The second one as a lifecycle file looks like this:

{
  "rule": [
    {
      "action": { "type": "AbortIncompleteMultipartUpload" },
      "condition": { "age": 2 }
    }
  ]
}

Next: Configure CORS on the bucket.