Access keys

Access keys are how clients authenticate to the S3 API. Every key is a pair:

• An access key ID, which looks like rs_ak_stg_8f3c2b1a9d4e6f0c5b7a2e8d1f4c6b9a3e7d5f2c1b8a. Safe to log and store next to your code.
• A secret access key, which looks like rs_sk_stg_4d8e1c5f2b9a7e3d0c6b8f1a4e9d2c5b7f3a0e6d8c1b5f9a3e7d2c0b4f8a1e6d3c9b. Keep it secret and treat it like a password.

Both follow the standard AWS S3 protocol: clients sign requests with AWS Signature v4, the same algorithm used against Amazon S3.

Two kinds of keys

Runsite issues two types of keys, picked at creation time:

Type	Where you create it	What it can touch
Workspace-wide	Storage list page → Create API Key	Every bucket in the workspace.
Per-bucket	Bucket → Keys tab → Create Bucket Key	One specific bucket. Cannot list, read or write any other bucket.

Use the narrowest key that fits the job: one per app, one per CI environment, one per teammate. Revoking a narrow key never breaks anyone else.

Permissions

Each key carries a permission set. The dashboard exposes four flags:

Permission	Allows
read	List buckets and objects, download (GET / HEAD) objects.
write	Upload and overwrite (PUT, POST, multipart) objects.
delete	Delete objects.
admin	Manage buckets and bucket settings (create, configure, delete buckets).

Per-bucket keys are simplified to two presets:

• Read-only lists and downloads from one bucket.
• Read & Write uploads, reads and modifies in one bucket, but cannot delete.

Creating a key

Workspace-wide

1. Open Storage in the workspace sidebar.
2. Click Create API Key in the top-right.
3. Give it a name. Optional, but something like production-api, ci-uploads or backup-job saves you guessing later.
4. Pick the permission flags you need.
5. Click Create Key.

The dialog now shows the access key, secret key, the endpoint URL and a copy-pasteable boto3 snippet. Copy the secret immediately. It is shown once and cannot be retrieved later.

Per-bucket

1. Open the bucket from the Storage list.
2. Switch to the Keys tab.
3. Click Create Bucket Key.
4. Pick Read-only or Read & Write.
5. Click Create Key.

Same one-time-display rule applies.

What the dashboard hands you

Every freshly created key comes with everything you need to plug it into an SDK:

Access Key   rs_ak_stg_8f3c2b1a9d4e6f0c5b7a2e8d1f4c6b9a3e7d5f2c1b8a
Secret Key   rs_sk_stg_4d8e1c5f2b9a7e3d0c6b8f1a4e9d2c5b7f3a0e6d8c1b5f9a3e7d2c0b4f8a1e6d3c9b
Endpoint     https://s3.runsite.app
Region       auto

These four values are everything any S3 client needs.

Storing keys safely

The secret is a password

Treat the secret access key the same way you treat a database password. Anyone with the pair can read, write or delete data inside the key’s scope. There is no second factor.

Recommended practice:

• Put both values into your service’s environment variables, and never commit them to the repo.
• For a Runsite Web Service, add them under Settings → Environment:

  S3_ENDPOINT_URL=https://s3.runsite.app
  S3_ACCESS_KEY_ID=rs_ak_stg_…
  S3_SECRET_ACCESS_KEY=rs_sk_stg_…
  S3_REGION=auto
  S3_BUCKET=user-uploads

• Browser-side code must never hold the secret. Use presigned URLs or proxy through your backend.
• Use one key per environment (development / staging / production) so you can rotate them independently.

Listing and revoking keys

• Workspace-wide keys live on the Storage list page, in the API Keys section.
• Per-bucket keys live on the Keys tab inside the bucket.

For each key the dashboard shows the name, the access key ID, the permissions and a delete button. Deleting a key revokes it instantly. Any client still using it starts getting 403 Forbidden on the very next request.

Rotation

There is no built-in expiration. To rotate:

1. Create a new key with the same permissions.
2. Update the credentials in your service / CI / clients.
3. Delete the old key.

Doing it in this order means no downtime, because both keys are valid during the cut-over.