> For the complete documentation index, see [llms.txt](https://docs.neova.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.neova.io/neova/peer-to-peer-network/swarm-accelerator-our-own-cdn.md).

# Swarm Accelerator - Our own CDN

The read gateway of the Neova swarm. Ranked providers, hedged fetches, and a cache for the files people open again.

The indexer can name the best node. A download still fails the user if that node stalls and nothing else is tried.

The **Swarm Accelerator** is the read gateway of the Neova swarm. When you open a file in NeoDrive, the browser is sent to the accelerator. It resolves the CID, fetches the bytes from the healthiest providers, and returns them. If it has served that CID recently, it returns them from cache.

The design is public, next to the indexer work: [Optimizing Private IPFS: Swarm Accelerator](https://discuss.ipfs.tech/t/optimizing-private-ipfs-swarm-accelerator/20182).

### A read that refuses to wait

A plain IPFS fetch picks a peer and waits. Distance, a busy disk, or a peer that is about to drop all become the user’s latency.

The accelerator takes the scored provider list and treats it as a race with a head start:

1. Ask the Private Indexer for the providers of this CID, best score first.
2. Open the fetch on the first provider.
3. If bytes have not started within about **200 milliseconds**, open the next provider, up to **three** in flight. The first complete response wins. The slower attempts are dropped.
4. Store the result. A following read, from you or from someone else on the same file, can be served from cache for about **10 minutes**.

That pattern is hedging. The preferred provider still goes first, because the score exists for a reason. A second and third path exist so a slow preferred provider cannot hold the file hostage. A small number of block ranges can be in flight together, so a large file keeps moving instead of waiting out one range at a time.

The first open pays the network. The second open, a minute later, usually pays the cache.

### Where it sits

```
Browser
    │
    ▼
NeoDrive
    resolves the CID, checks permission
    redirects to the gateway
    │
    ▼
Swarm Accelerator
    │
    ├── cache hit  →  respond
    │
    └── cache miss →  Private Indexer
                         │
                         ▼
                      up to 3 Kubo providers
                      hedged, best score first
```

NeoDrive stays on the account side of this picture. It authorizes the download and redirects. It does not stream the file through the application server. The gateway and the nodes carry the bytes, which is what keeps a busy drive from turning the API into a file proxy.

Uploads take the other door. The encrypted stream goes to Kubo, the node pins it, and the announcer tells the indexer. The accelerator joins the story when someone wants the file back.

### A gateway for fingerprints

A conventional CDN copies objects that live at URLs. The accelerator copies nothing that it cannot check. The address is a CID. A wrong byte fails the hash. The providers it contacts are members of the private swarm, ranked by the indexer, and reached over the swarm’s own addresses.

The gateway can run next to the core of the network, and an operator node can run one closer to its own users. Local reads stay local when the content is nearby. The central indexer remains the source of truth for who holds the CID. Cache is an optimization. The registry is the map.

### What this changes in the product

People describe IPFS as slow because discovery is slow and the first peer is often the wrong one. The indexer removes the walk. The accelerator removes the single point of waiting. Together they are why a file in NeoDrive opens like a file, including on a network that is genuinely distributed.

The same gateway serves any application that stores on the swarm and reads by CID. NeoDrive is the first. Backup, export, and later Neova services can use the same read path without inventing another one.

The accelerator moves ciphertext. It does not hold keys, and it does not decrypt. Speed on the read path leaves encryption exactly where it was: in the browser, before the upload, and in the browser again after the download.