Skip to content
Get started

Popular

Platform AI website builder Compute GPU cloud marketplace OS Workspace & coworker Storage Permanent file storage Sovereign Self-hosted AI

Compute & Infrastructure

Compute — GPU cloud GPU / Earn VM — instances Inference Sovereign AI Storage

Build & Agents

Platform Agent Studio Agents API SaaS Builder Visual Editor Edit — chat

AI & Workspace

OS — workspace Cowork — messaging Memory Image Bank Assistant Analytics

Trust & Verification

Verify Receipt verifier Trust SKU Federation R-Series on DCS AI Research & specs at DCS Labs →
View all products → One platform · one sign-in · every product on dcsai.ai

DCS AI Technologies

About All products Agent Profiles Solutions Pricing Careers Contact

DCS Labs Research

Labs home → R-Series standard Trust Landscape Research policy Live stats

Developers

Developer hub Documentation API reference MCP server Connectors Changelog

Solutions

Government Healthcare Finance Agencies Sovereign & regulated Enterprise

Company

About Team Blog Press Investors Customers

Status & trust

Status Compliance Legal Privacy Whitepapers Full sitemap
View full sitemap → DCS AI Technologies L.L.C, Dubai · parent of DCS Network + DCS Labs
Gateway

Home  /  Gateway

🌏 Public IPFS / Filecoin gateway

Your CID, served from anywhere.

DCS Gateway is a Cloudflare-Worker fronted IPFS / Filecoin gateway with a four-upstream fallback chain and a 30-day edge cache. One primary, one cold-standby on a separate Cloudflare account — flippable in about two minutes.

https://gateway.dcsai.ai/ipfs/
1
trustless-gateway.linkstandby leads with the most-Lighthouse-friendly upstream
waiting
—
2
w3s.linkWeb3.Storage gateway — the primary's first upstream
waiting
—
3
4everland.ioAsia-routed fallback, fast on long-tail CIDs
waiting
—
4
ipfs.ioProtocol Labs reference gateway — the ultimate fallback
waiting
—
✓  200 OK — first hit wins, cached for 30 days at the edge.
payload · 142 KB · via trustless-gateway.link · 386 ms
Architecture

One primary. One standby. Four upstreams.

Same path scheme, same envelope, different fallback order. The standby lives in a separate Cloudflare account so a single-account outage can't take both down.

💻
Client any browser, any region
→
⚡
gateway.dcsai.ai · Worker A Cloudflare Account 1 · primary route
🎥
gateway-standby.dcsai.ai · Worker B Cloudflare Account 2 · pre-warmed cold standby (DNS swing — ~2 min)
→
1. trustless-gateway.linkLighthouse-friendly · primary's #2 / standby's #1
2. w3s.linkWeb3.Storage · primary's #1 / standby's #2
3. 4everland.ioAsia-routed · long-tail CIDs
4. ipfs.ioProtocol Labs reference · final fallback
→
💾
30-day edge cache (Cloudflare Cache API) First 200 / 206 response wins and is pinned at the edge for 30 days
CID INPUT bafy…7h2x GET DCS Gateway gateway.dcsai.ai CACHE HIT 12ms index.html 14.2 KB · text/html 200 OK served from 3 SPs no API key · no rate limit · permanent address
Why this gateway

The properties a free IPFS gateway can't give you

Six guarantees the Cloudflare-Worker shape is uniquely good at.

🌏

Anycast every region

Cloudflare's anycast network means the closest edge POP serves your CID — sub-100ms hot reads from every populated continent.

💾

30-day edge cache

Every successful upstream fetch caches at the edge for 30 days. Repeat reads bypass the upstream fallback chain entirely.

🔗

Four-deep fallback chain

If trustless-gateway.link is slow, the Worker falls through w3s.link, 4everland.io and ipfs.io. First 200 / 206 wins.

🎥

Hot cold-standby

A second Worker on a separate Cloudflare account is pre-warmed. DNS at gateway.dcsai.ai swings to it in roughly two minutes.

🔒

CORS for the DCS family

An explicit allowed-origins list (dcsai.ai, storage, compute, pilot, sovereign, verify) ships out of the box.

⏱

60 req/min per IP

Per-IP rate limit at 60 RPM keeps the free-tier headroom usable for every customer and slows down obvious abuse without hurting normal browsing.

The whole worker config

Boring on purpose

One file. No build step. Cloudflare Pages auto-deploys on push.

wrangler.toml · Cloudflare Worker config compatibility-date 2026-05-18
# DCS Gateway — one worker, four upstreams, 30-day cache name = "dcs-kubo-gateway" main = "src/worker.ts" compatibility_date = "2026-05-18" [vars] ALLOWED_ORIGINS = "https://dcsai.ai,https://storage.dcsai.ai, https://compute.dcsai.ai,https://pilot.dcsai.ai, https://sovereign.dcsai.ai,https://verify.dcsai.ai" RATE_LIMIT_PER_MIN = "60" CACHE_TTL_SECONDS = "2592000" # 30 days UPSTREAMS = [ "https://trustless-gateway.link", "https://w3s.link", "https://4everland.io", "https://ipfs.io", ] [assets] directory = "./public" # this landing page
Public endpoints

Hit any of these directly

Every endpoint is read-only and unauthenticated. Drop them into any client.

GET /ipfs/<cid>/<path?> Content-addressed file fetch. Same path scheme as ipfs.io and w3s.link.
GET /ipns/<name>/<path?> Mutable-name resolution; the Worker proxies upstream IPNS lookups.
GET /health Returns { status: "ok", upstreams: [...], cache: "ok" } for monitor probes.
GET /status JSON breakdown: per-upstream success rate, cache hit rate, rate-limit state.
OPTIONS /ipfs/* CORS pre-flight returns the allowed-origins list — honoured by every browser.
GET / · OPTIONS / This landing page (served from ./public) and CORS pre-flight.
<100 msHot-read latency (cached)
4 upstreamsFallback chain depth
30 daysEdge cache TTL
~2 minStandby failover RTO
60 RPMPer-IP rate limit
Where it fits

The serving layer under permanence

🗃

Storage

Pins the bytes; Gateway serves them.
✅

Verify

Re-hashes the bytes you just fetched.
🕒

Status

Live health of every gateway endpoint.
🔬

DCS Labs

The R-Series spec and verifier package.
Gateway FAQ

The questions clients ask first

Is the gateway free to use?
For DCS customers, yes — included on every tier. The 60 req/min per-IP limit applies to everyone; if you need more, point a client at any of the upstream gateways directly (same CIDs, same bytes).
How is this different from ipfs.io or w3s.link?
Anycast edge in front of a four-deep fallback chain plus a 30-day cache. Each individual upstream can have a bad minute and your CIDs keep serving from cache or the next-best upstream — not just the one you bookmarked.
What happens when Cloudflare's free tier hits its daily limit?
The Status page surfaces an "approaching quota" warning when usage hits ~85% of the daily budget. DNS at gateway.dcsai.ai is pre-staged to swing to gateway-standby.dcsai.ai (separate Cloudflare account) in roughly two minutes. Cached objects continue serving from the original edge during the swing.
Does the gateway store anything itself?
Only ephemeral edge cache (Cloudflare Cache API) — 30-day TTL. The actual permanence comes from Filecoin via Storage. The gateway is the read path, not a storage tier.
How are receipts handled?
Receipts emitted under the primary Worker stay valid under the standby — the receipt chain is keyed by CID, not by serving Worker. CID semantics are stable; neither Worker mutates content.
Can I run my own gateway against the same upstream order?
Yes — the Worker source is at github.com/DCS-Platform/dcs-kubo-gateway (MIT). Fork it, change the upstream list, point your domain at the Worker. The deploy script handles Cloudflare Pages binding.
What about CORS for non-DCS origins?
The published Worker's CORS list is fixed to the DCS family by default; a customer-hosted fork lets you replace ALLOWED_ORIGINS in wrangler.toml. The path scheme stays compatible with every public IPFS gateway.