Unlike Google Drive, Google Cloud Storage (GCS) has no service-account quota gotchas. The storage belongs to your GCP project, so a service account can read and write freely as long as it has the right IAM roles on the bucket. This makes GCS the simplest "real" destination for service-account migrations.
Step 1 — Create a GCP project and enable billing
Sign in to console.cloud.google.com. Create a project (or pick an existing one) and enable billing for it. GCS will refuse API calls on a no-billing project, even within the free tier.
Billing → Link a billing accountA credit card is required, but typical migrations of a few GB cost less than a coffee.
Step 2 — Create or pick a bucket
Go to Cloud Storage → Buckets → Create.
Name
Globally unique. Examples:acme-assets-prod,migrated-2026-q2.Location
Single-region is cheapest; multi-region is for global distribution. Pick something close to your other infra.Storage class
Standard for active migrations. Switch to Nearline/Coldline later if you're archiving.Access control
Uniform (recommended) — IAM applies to all objects. Avoid Fine-grained unless you have legacy ACLs to support.Encryption
Default Google-managed keys are fine for almost everyone. CMEK only if your compliance team has asked.
Step 3 — Create a service account
Navigate to IAM & Admin → Service Accounts → Create Service Account.
- Name:
asset-migrator-gcs - Description: "Used by Univaultport for GCS migrations" (optional)
- Skip the optional project-level role step — we'll grant bucket-scoped permissions instead, which is the principle-of-least-privilege way.
Click Done.
Step 4 — Grant the service account access to the bucket
This is the step most teams get wrong. Project-level Storage roles work but grant access to every bucket in the project. Bucket-level roles are scoped and recommended.
Go back to Cloud Storage → Buckets → your bucket → Permissions → Grant Access.
- Principal: paste the service account email (looks like
asset-migrator-gcs@my-project.iam.gserviceaccount.com) - Role: choose one of the following based on use case:
| Use case | Role | What it allows |
|---|---|---|
| Source only (read migrations FROM GCS) | Storage Object Viewer | List + download |
| Destination only (write migrations TO GCS) | Storage Object Creator | Upload only — no list |
| Source and destination | Storage Object Admin | Read, write, delete |
| Full management | Storage Admin | Everything, including bucket-level operations |
Click Save.
Step 5 — Generate a JSON key
Back at IAM & Admin → Service Accounts, click into your service account → Keys → Add Key → Create new key → JSON → Create.
A JSON file downloads. Open it — you'll paste its full contents into Univaultport.
Step 6 — Paste credentials into Univaultport
In the connector wizard:
Service Account JSON
Paste the entire JSON key file (including the{and}).Bucket Name
The bucket name only — nogs://prefix, no project prefix. e.g.acme-assets-prod.Object Prefix
Optional. Scopes the connector to a sub-path inside the bucket. e.g.images/2026/. Every read and write happens under this prefix.
Hit Save & test. A green check means GCS responded successfully.
What the prefix actually does
GCS is flat object storage — "folders" are virtual. Setting prefix: images/2026/ means:
- Listings only return objects whose keys begin with
images/2026/. - Writes prepend
images/2026/to every uploaded asset key. - Folder navigation in the UI is scoped to that subtree.
This is useful for multi-team buckets where each team owns a top-level prefix. Leave it blank to use the entire bucket.
Troubleshooting
| Error | Cause | Fix |
|---|---|---|
403 Forbidden | Service account is missing the IAM role on the bucket | Grant the role at the bucket level, not just the project |
404 Bucket not found | Typo in bucket name, or bucket is in a different project | Double-check the name; remove any gs:// prefix |
Caller does not have storage.objects.list access | Has Creator but not Viewer | Switch to Object Admin if you need to list |
| Billing required | Project has no billing account | Link a billing account; free tier still applies |
Cost estimate
For a one-time migration of 100 GB to/from GCS in Standard storage:
- Storage: $0.020/GB/month → ~$2/month while resident
- Operations: $0.005 per 10,000 PUTs → essentially free for typical migrations
- Egress (downloads to outside Google Cloud): $0.12/GB → factor this in for large migrations leaving GCS
For migrations between GCS buckets in the same region, egress is free.
Next steps
With GCS connected, common patterns are:
- GCS → Cloudinary for CDN-fronted delivery of asset libraries
- Cloudinary → GCS for archive/backup of legacy DAM libraries
- Local → GCS for initial cloud onboarding of on-prem assets
Pick a source and destination in the migration wizard and you're off.
