> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataraven.io/llms.txt
> Use this file to discover all available pages before exploring further.

# MEGA S4

> Connect MEGA S4 buckets as sources and destinations for transfer tasks.

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

|                    |                                                                                          |
| ------------------ | ---------------------------------------------------------------------------------------- |
| **Region**         | Required — e.g., `eu-amsterdam`                                                          |
| **Endpoint URL**   | Derived from region — `https://s3.<region>.megas4.com`                                   |
| **Credentials**    | Access key — `access_key_id`, `secret_access_key`                                        |
| **Task defaults**  | `s3_no_check_bucket: true`, `fast_list: true`, `transfers: 32`, `checkers: 16`           |
| **Notable limits** | \~40–50 upload requests/s per account; designed for up to \~20M objects per account      |
| **Provider docs**  | [MEGA S4](https://mega.io/objectstorage) · [S4 help centre](https://help.mega.io/megas4) |

`fast_list` is on by default — MEGA's own
[rclone guide](https://help.mega.io/megas4/setup-guides/rclone) recommends `--fast-list` when
scanning large directory trees: fewer listing calls, at the cost of more memory. See
[Performance and Rate Limits](#performance-and-rate-limits) for the rest of the tuning picture.

## Credentials

Create a [secret](/secrets) with the **MEGA S4** provider type. The auth method is
`mega_s4_access_key`, which requires:

| Field               | Description               |
| ------------------- | ------------------------- |
| `access_key_id`     | MEGA S4 access key ID     |
| `secret_access_key` | MEGA S4 secret access key |

Create access keys from the MEGA S4 console — see
[MEGA's S4 help centre](https://help.mega.io/megas4) for a walkthrough. S4 exposes a real
[IAM API](https://github.com/meganz/s4-specs) (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

| Field             | Value                                                              |
| ----------------- | ------------------------------------------------------------------ |
| **region**        | Required — e.g., `eu-amsterdam`                                    |
| **endpoint\_url** | Optional — derived from region as `https://s3.<region>.megas4.com` |

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:

| Field          | Example value    |
| -------------- | ---------------- |
| name           | `MEGA S4 EU`     |
| location\_type | MEGA S4          |
| bucket\_name   | `acme-transfers` |
| region         | `eu-amsterdam`   |

## Provider Quirks

### Object key restrictions

<Warning>
  MEGA S4 validates object keys more strictly than S3 and Azure Blob, and rejects the request
  rather than normalizing the key. A transfer carrying any of these will fail on the affected
  objects mid-run:

  * Consecutive forward slashes (`//`)
  * `/./` or `/../` anywhere in the key, or a key equal to `..`, beginning `../`, or ending `/..`
  * Keys shorter than 1 or longer than 1024 characters
  * Keys ending in `/` on an object that has content

  S3 and Azure Blob both permit `//`, so keys carried over from either can hit this. Check your
  source keys before transferring to MEGA S4.
</Warning>

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](https://help.mega.io/megas4/setup-guides/rclone) recommends.

## Performance and Rate Limits

S4 rate-limits uploads at roughly **40–50 requests per second per account**, and MEGA's
[rates guidance](https://help.mega.io/megas4/setup-guides/mega-s4-rate-limits-and-performance-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](mailto: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](https://github.com/meganz/s4-specs)). If you're migrating from S3
with versioning and lifecycle rules, here is what arrives:

| S3 feature                    | On MEGA S4                                                                                        |
| ----------------------------- | ------------------------------------------------------------------------------------------------- |
| Object data & metadata        | Transfers                                                                                         |
| Versioning                    | Not supported — the current version of each object transfers; version history does not carry over |
| Object lock / legal hold      | Not supported — retention settings do not carry over                                              |
| Object tags                   | Not supported — tags do not carry over                                                            |
| Server-side encryption config | The S3 SSE options (SSE-S3, SSE-KMS, SSE-C) do not exist on S4                                    |
| Storage classes               | Every object lands as `STANDARD` — there are no other classes and no lifecycle rules              |

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](/guides/import-rclone-config).