The tport.space pixel t and cloud mark on a violet-to-pink tile

S3-compatible does not mean that every storage service is the same service. It means a client can speak the familiar S3 request and signing format to a different endpoint. That matters because the skills and automation you already have — command-line copies, rclone jobs and Python scripts — can move with your bucket instead of being rewritten around one vendor’s dashboard.

For tport.space, start with a bucket and an access key from the console. Keep the secret in a password manager or your system’s credential store, never in a repository. The endpoint used in the examples is https://s3.tport.space, the region is auto, and path-style requests are the safest starting point while you are proving a configuration.

The four values every client needs

text
Value                 Example                         Why it matters
Endpoint              https://s3.tport.space          sends requests to your storage
Access key ID         TPS_ACCESS_KEY_ID               identifies the key
Secret access key     stored outside source control    signs each request
Region                auto                            part of the SigV4 signature
Bucket                site-backups                    top-level container
Addressing style      path                            avoids DNS-style bucket assumptions

The endpoint is the portability switch. AWS CLI exposes it as --endpoint-url; rclone calls it endpoint; boto3 calls it endpoint_url. If a command accidentally talks to the default AWS endpoint, stop there — a successful command against the wrong account is worse than a clear error.

AWS CLI: a small, reversible smoke test

bash
export AWS_ACCESS_KEY_ID='your-access-key'
export AWS_SECRET_ACCESS_KEY='your-secret-key'
export AWS_DEFAULT_REGION='auto'

aws --endpoint-url https://s3.tport.space s3api list-buckets
printf 'endpoint test %s\n' "$(date -u +%FT%TZ)" > endpoint-test.txt
aws --endpoint-url https://s3.tport.space s3 cp endpoint-test.txt s3://site-backups/tests/endpoint-test.txt
aws --endpoint-url https://s3.tport.space s3 cp s3://site-backups/tests/endpoint-test.txt -
aws --endpoint-url https://s3.tport.space s3 rm s3://site-backups/tests/endpoint-test.txt

That sequence uses one small object and removes it only after reading it back. list-buckets confirms that the key can see buckets; the copy/read/remove sequence proves the three permissions a backup job normally needs. AWS CLI documents --endpoint-url as the global override, and its list-buckets command is paginated — do not build an inventory script that assumes one unbounded response.

rclone: a reusable remote

ini
# rclone config create tport s3
[tport]
type = s3
provider = Other
access_key_id = your-access-key
secret_access_key = your-secret-key
endpoint = https://s3.tport.space
region = auto
force_path_style = true
bash
rclone lsd tport:
rclone mkdir tport:site-backups/tests
rclone copy ./public tport:site-backups/tests/public --progress
rclone check ./public tport:site-backups/tests/public --one-way

rclone’s S3 backend supports many S3-compatible providers; provider = Other is the conservative choice for an endpoint that is not a named preset. rclone check is valuable after a first move because it compares the source and destination rather than treating a zero exit from copy as proof that every expected file arrived.

boto3: set the endpoint on the client, not in each operation

python
import os
import boto3
from botocore.config import Config

s3 = boto3.client(
    's3', endpoint_url='https://s3.tport.space', region_name='auto',
    aws_access_key_id=os.environ['TPS_ACCESS_KEY_ID'],
    aws_secret_access_key=os.environ['TPS_SECRET_ACCESS_KEY'],
    config=Config(s3={'addressing_style': 'path'}),
)
s3.upload_file('build/site.zip', 'site-backups', 'releases/site.zip')
print(s3.head_object(Bucket='site-backups', Key='releases/site.zip')['ContentLength'])

Keeping credentials in environment variables here prevents them being committed beside the program. The head_object result supplies an exact byte count after the upload. For a 314,572,800-byte archive, that is 300 MiB (314,572,800 ÷ 1,048,576), so an expected-size check can catch a truncated local build before a restore day.

s3cmd: configure endpoint and host separately

ini
# ~/.s3cfg — protect this file: chmod 600 ~/.s3cfg
access_key = your-access-key
secret_key = your-secret-key
host_base = s3.tport.space
host_bucket = s3.tport.space/%(bucket)
use_https = True
signature_v2 = False
bash
s3cmd ls
s3cmd put endpoint-test.txt s3://site-backups/tests/endpoint-test.txt
s3cmd get s3://site-backups/tests/endpoint-test.txt -
s3cmd del s3://site-backups/tests/endpoint-test.txt

With host_bucket = s3.tport.space/%(bucket), s3cmd uses a path-style bucket URL rather than trying to create a hostname from the bucket name. Keep Signature Version 4 enabled (signature_v2 = False): current S3-compatible services normally expect it.

A practical compatibility checklist

text
1. Create a non-production test prefix, such as tests/cli-2026-10-31/.
2. Upload one text file; download it; compare bytes locally.
3. List only that prefix and confirm the key sees the expected object.
4. Delete that object and list the prefix again.
5. Record the working endpoint, region and addressing style beside the job.
6. Only then point a scheduled backup or deployment at the production prefix.

Use a dedicated, narrowly scoped key when the console permits it: a backup process should not need to create unrelated buckets. Also test the exact features you rely on. A plain object upload says nothing about versioning, object-lock semantics, ACLs, website hosting or a provider-specific encryption option. Compatibility is strongest when you stay with standard bucket and object operations.

What moves cleanly — and what needs a test

text
Usually portable                    Confirm before relying on it
Put/Get/Delete object                Bucket versioning and object lock
List objects with a prefix           ACL and policy dialects
Multipart upload                     Static-website behaviour
Presigned GET/PUT URLs               Event notifications and replication
SigV4 access-key signing             Provider-specific storage classes

Once your small test works, the same endpoint can serve a deployment artifact, a media upload or a backup. For the next practical use, follow our rclone website-backup runbook and include a restore test — an object that exists is not yet a backup you know how to use.

Create a bucket and access key, then connect the S3 client you already use.

Open tport.space

Sources

AWS, AWS CLI list-buckets reference (global --endpoint-url, pagination and parameters), consulted 31 October 2026.
rclone, Amazon S3 backend documentation (S3 backend, provider compatibility and configuration options), consulted 31 October 2026.
AWS, Boto3 S3 guide (S3 client operations and transfers), consulted 31 October 2026.
s3tools, Using s3cmd with S3-compatible services (endpoint configuration concepts), consulted 31 October 2026.