mirror of
https://github.com/supabase/supabase.git
synced 2026-06-20 21:16:00 +08:00
0aa7b4965f
Contributes to DOCS-1052 Contributes to DOCS-1057 ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Resolves linting warning for "let's" and adds an exception for product name. ## Tophatting 1. Read the diff and see if changes make sense in context. 2. Run `pnpm lint:mdx`, search for "let's" and see no instances. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated instructional copy across multiple AI, authentication, database, functions, realtime, storage, and troubleshooting guides to improve clarity and consistency. * Replaced conversational phrasing (for example, “Let’s…/Let’s see…”) with direct imperatives, tightened example lead-ins, and adjusted a few step explanations for readability. * Refreshed some tutorial text and code-sample presentation in guides (no behavioral changes). * Added/adjusted minor MDX lint guidance in a couple of documents. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Nik Richers <nrichers@gmail.com>
36 lines
2.6 KiB
Plaintext
36 lines
2.6 KiB
Plaintext
---
|
|
id: 'storage-cdn'
|
|
title: 'Storage CDN'
|
|
description: 'Learn how Supabase Storage caches objects with a CDN.'
|
|
sidebar_label: 'CDN'
|
|
---
|
|
|
|
All assets uploaded to Supabase Storage are cached on a Content Delivery Network (CDN) to improve the latency for users all around the world. CDNs are a geographically distributed set of servers or **nodes** which cache content from an **origin server**. For Supabase Storage, the origin is the storage server running in the [same region as your project](/dashboard/project/_/settings/general). Aside from performance, CDNs also help with security and availability by mitigating Distributed Denial of Service (DDoS) and other application attacks.
|
|
|
|
### Example
|
|
|
|
The following example shows how a CDN helps with performance.
|
|
|
|
A new bucket is created for a Supabase project launched in Singapore. All requests to the Supabase Storage API are routed to the CDN first.
|
|
|
|
A user from the United States requests an object and is routed to the U.S. CDN. At this point, that CDN node does not have the object in its cache and pings the origin server in Singapore.
|
|
|
|
|
|
Another user, also in the United States, requests the same object and is served directly from the CDN cache in the United States instead of routing the request back to Singapore.
|
|
|
|
|
|
<Admonition type="note">
|
|
|
|
Note that CDNs might still evict your object from their cache if it has not been requested for a while from a specific region. For example, if no user from United States requests your object, it will be removed from the CDN cache even if we set a very long cache control duration.
|
|
|
|
</Admonition>
|
|
|
|
The cache status of a particular request is sent in the `cf-cache-status` header. A cache status of `MISS` indicates that the CDN node did not have the object in its cache and had to ping the origin to get it. A cache status of `HIT` indicates that the object was sent directly from the CDN.
|
|
|
|
### Public vs private buckets
|
|
|
|
Objects in public buckets do not require any authorization to access objects. This leads to a better cache hit rate compared to private buckets.
|
|
|
|
For private buckets, permissions for accessing each object is checked on a per user level. For example, if two different users access the same object in a private bucket from the same region, it results in a cache miss for both the users since they might have different security policies attached to them.
|
|
On the other hand, if two different users access the same object in a public bucket from the same region, it results in a cache hit for the second user.
|