MEGA S4

MEGA’s S3-compatible object storage. Buckets are global — readable through any regional endpoint — and both object keys and bucket names are validated more strictly than on S3 or Azure.

​

At a Glance

fast_list is on by default — MEGA’s own rclone guide recommends --fast-list when scanning large directory trees: fewer listing calls, at the cost of more memory. See Performance and Rate Limits for the rest of the tuning picture.

​

Credentials

Create a secret with the MEGA S4 provider type. The auth method is mega_s4_access_key, which requires: Create access keys from the MEGA S4 console — see MEGA’s S4 help centre for a walkthrough. S4 exposes a real IAM API (users, groups, policies), so keys can be scoped down with a bucket policy rather than granting account-wide access — worth doing for a transfer key that only needs one bucket. One key works for every region: buckets are global and reachable through any regional endpoint, so you do not need a secret per region.

​

Location Setup

Because buckets are global, the region picks the endpoint closest to your workload rather than where the data lives. Available regions are eu-amsterdam, eu-luxembourg, eu-paris, eu-barcelona, ca-montreal, ca-vancouver, and ap-tokyo. Legacy s3.<region>.s4.mega.io endpoints still work — enter one in the endpoint field to override the derived value. MEGA also operates a global endpoint, s3.g.megas4.com (currently routed to Amsterdam), and publishes numbered per-datacenter hostnames such as s3.eu-amsterdam-1.megas4.com; the derived s3.<region>.megas4.com names are stable aliases for those, so any of the three forms can go in the endpoint field. Example:

​

Provider Quirks

​

Object key restrictions

Checking source keys is a manual step today — a pre-flight scan that flags incompatible keys before the transfer starts is planned.

​

Bucket naming

Bucket names are also stricter than S3’s:

• 3–63 characters
• Lowercase letters, numbers, dots, and hyphens only
• Must begin and end with a letter or number
• No .., .-, or -. sequences
• Not formatted as an IP address
• No reserved prefix (xn--, sthree-, amzn-s3-demo-) or suffix (-s3alias, --ol-s3, .mrap, --x-s3, --table-s3)

DataRaven checks these rules when you create the location, so a non-conforming name fails immediately with a clear message instead of surfacing later as a confusing AccessDenied from the service.

​

Objects uploaded through MEGA’s own apps

Files placed in S4 by MEGA’s own software don’t store an MD5 hash in their ETag, so S3 clients that verify checksums — rclone included — can fail integrity validation when copying those objects out of S4. Objects written through the S3 API (including everything DataRaven transfers in) are unaffected. If your source bucket holds MEGA-app-uploaded data, set ignore_checksum in the task’s rclone configuration — the transfer then verifies by size and modification time instead, as MEGA’s rclone guide recommends.

​

Performance and Rate Limits

S4 rate-limits uploads at roughly 40–50 requests per second per account, and MEGA’s rates guidance puts the practical ceiling at ~42–45 objects per second regardless of concurrency. For transfer tasks that means:

• Many small objects hit the request cap before bandwidth does. Larger objects and multipart uploads make far better use of throughput; raising transfers past ~45 buys nothing.
• SlowDown responses are throttling, not failure. rclone backs off and retries automatically; if they persist in the execution logs, lower transfers in the task’s rclone configuration.
• DataRaven applies MEGA’s suggested starting point — transfers: 32, checkers: 16 — as the default for tasks that touch an S4 location. Override either in the task’s rclone configuration if your workload calls for it. (Plan limits still apply: Free-tier executions run with transfers: 1.)
• s3_upload_cutoff is workload-dependent — MEGA’s guidance pulls it in opposite directions. Tune it for whichever shape dominates the transfer:
  • Mostly large objects (1GB+): set the cutoff low (64M–256M) so big files always use multipart, and scale s3_chunk_size / s3_upload_concurrency rather than file-level parallelism.
  • Mostly small objects: set the cutoff high (256M–1G) so files stay single PUT — one request per object instead of several, and single-PUT objects keep their MD5 ETags.
• s3_no_head trades verification for request budget. It saves one API call per object, which matters against the request cap — but rclone then assumes every upload succeeded exactly as sent (size, modtime, metadata), so a truncated or corrupted upload can go undetected. Leave it off unless the request cap is your actual bottleneck, and avoid combining it with ignore_checksum: together they leave a transfer with essentially no post-upload verification.
• Accounts are designed for up to ~20 million objects. For workloads beyond that — or bursty, object-heavy ones — MEGA asks that you contact the S4 team at S4@mega.io.
• Large deletes: MEGA recommends moderate DeleteObjects batches (~100 objects) and not running massive delete workloads alongside heavy uploads — relevant for sync tasks that prune many destination objects.

​

What Transfers — and What Doesn’t

S4 stores object data and standard metadata, but several S3 features have no S4 equivalent (per MEGA’s published API spec). If you’re migrating from S3 with versioning and lifecycle rules, here is what arrives: If you rely on version history or object-lock retention at the source, keep the source bucket — a transfer to S4 carries the current objects, not those controls.

​

Importing from rclone.conf

MEGA S4 remotes appear in rclone.conf as type = s3 with provider = Mega. Configs written before rclone gained that provider value are recognized by their endpoint hostname instead (*.megas4.com or the legacy *.s4.mega.io). Note that rclone’s mega type is the consumer MEGA cloud drive, a different product — it is not supported and is skipped by the importer. MEGA S4 object storage always arrives as type = s3. See the rclone import guide.