PopCloud documentation

S3-compatible object storage. If your code already talks to S3, it already talks to PopCloud — change the endpoint and credentials, then choose path-style or virtual-hosted addressing.

What this is

PopCloud speaks the S3 API. Standard SDKs, CLIs, framework adapters and backup tools keep their normal object workflows; point them at the PopCloud endpoint and use a PopCloud credential. Bucket administration and a small set of long-tail S3 operations differ, and those differences are documented explicitly.

What you get that a generic “S3-compatible” label does not promise: a published compatibility matrix generated from a test suite rather than from optimism, and a list of everything that does not work — on the way in, not after you have migrated.

Start here

QuickstartCredentials to a stored object, in your language, in about five minutes.Integrations (10 documented)Pick your stack. 10 more carry a configuration table while their pages are written.Migrate from AWS S3Inventory, cutover strategies, verification, and a rollback path.What works, what doesn'tGenerated from the compatibility suite. The page to read before you commit.

The whole configuration

Five values. Four of them are the standard AWS environment variables, which most SDKs read with no code at all; the fifth is the bucket, because there is no standard name for that.

Environment

example values

export AWS_ACCESS_KEY_ID=PCAK00EXAMPLEKEYID00
export AWS_SECRET_ACCESS_KEY=<your secret access key>
export AWS_ENDPOINT_URL=https://s3.canada.popcloud.ca
export AWS_REGION=canada
export POPCLOUD_BUCKET=pc-your-org-media

These are example values. Sign in and every snippet on this site fills in with your own endpoint, key and bucket.

Path-style addressing remains the safest choice for dotted bucket names and clients without nested wildcard TLS. Virtual-hosted addressing is supported too when the endpoint’s DNS and certificate cover the bucket hostname.