BYOC Setup

Bring-your-own-cloud is for teams who need source code blobs to live inside cloud accounts they already own and audit. Three concrete reasons it matters:

• Data sovereignty. Source never leaves the account, region, or jurisdiction you chose.
• Your encryption keys. The KMS key is owned by you. You can rotate it, restrict it, or rip it out — your code becomes unreadable to Velocity the moment you do.
• Your audit trail. Every read and write shows up in your CloudTrail / Azure Monitor / Cloud Audit Logs, not in a vendor dashboard you have to take on faith.

• AWS — commercial regions, including us-east-1, eu-west-1, ap-southeast-2, and the rest.
• AWS GovCloud — us-gov-east-1 and us-gov-west-1, with FIPS endpoints enforced.
• Microsoft Azure — any commercial region with Blob Storage + Key Vault.
• Azure Government — US Gov Virginia and US Gov Arizona.
• Google Cloud Platform — any region with Cloud Storage + Cloud KMS.
• GCP Assured Workloads — IL2, IL4, and IL5 controls supported.
• Generic S3-compatible — MinIO, Wasabi, Backblaze B2, Ceph, on-prem Cloudian. You provide endpoint + access key + secret.

BYOC onboarding lives in Org Settings → Storage → BYOC. The wizard is identical across providers — only the IAM artifact you copy is provider-specific.

1. Pick a provider and a region.
2. Copy the IAM policy JSON we generate. It scopes us to one bucket prefix and one key alias — nothing else.
3. Attach that policy to a fresh role / service principal / service account in your cloud, then paste the resulting ARN (or equivalent) back into Velocity.
4. Click Dry run. We assume the role, list what we'd create, and report success or the exact permission that's missing.
5. Click Confirm. Onboarding completes in about ten seconds.

Exactly two resources, both prefixed with your org UUID so they're trivially greppable in your account:

velocity-{org-uuid}            # the bucket (or storage container)
velocity-{org-uuid}-key        # the customer-managed KMS / Key Vault key

That's the entire footprint. We don't create roles, log groups, networking, queues, lambdas, functions, or anything else. The role you handed us is your artifact — you own its lifecycle.

Every BYOC operation that mutates your cloud has a dry-run pass. Before creation, we print the literal resource names, regions, and policies we'll attach, and we wait for an explicit confirm.

The dry-run output is also saved as JSON in your org's audit log — so a year later you can answer “what exactly did Velocity create in our AWS account?” without opening AWS Console.

If you started on Velocity's managed cloud and want to move to BYOC, the migration tool runs in four phases, all gated on your confirmation:

1. Copy. We stream every blob from our managed store into your new bucket. Source and destination are both encrypted; nothing hits disk in between.
2. Verify. SHA-256 of every object is compared. Mismatches abort the migration and we keep the managed-cloud copy intact.
3. Cut over. The storage backend pointer flips. New sessions read and write to your bucket immediately.
4. Wipe. Only after you click Confirm wipe managed-cloud copy do we delete the source. Until then it sits there as your fallback.

Cancelling BYOC or leaving Velocity? Run the uninstall script we generate per-org:

./velocity-byoc-uninstall.sh --org <uuid> --dry-run
./velocity-byoc-uninstall.sh --org <uuid> --confirm

It removes only the two velocity- prefixed resources and revokes the IAM attachments tied to them. Roles, accounts, networking, and anything else you provisioned yourself are untouched. The script is open source and lives in the same git repo as the rest of the BYOC tooling — you can read every line before running it.