CDN and Global Distribution for Deployments
We offer two kinds of Content Management Networks (depending on your pricing plan) for allowing your content to be served as fast as possible.
- BRU (Brussels, Belgium, West Europe)
- SFO (San Francisco, West US)
- GRU (São Paulo, Brazil)
- IAD (Washington DC, East US)
If you do not specify a region (which can be done using the
--region flag in Now CLI), your Lambdas will only be created in one of these regions: The one that is closest to you.
However, Static Files are served from all of these regions, no matter if
--region was used.
If you decide to upgrade to the Unlimited plan (which we highly recommend), you are granted access to our Full CDN. This term includes all of the regions mentioned above, plus over 150 more locations for caching: List of locations.
Thanks to the Full CDN, your Static Files will automatically be cached in any of those regions whenever they are requested (no manual changes needed). Furthermore, this also gives you the ability to cache the responses of your Lambdas in those regions too. For this to happen, you need to modify your code a little:
For your dynamic responses to be cached in all of these regions, adjust your code to send a Cache-Control header containing a
s-maxage (used for shared caches) parameter. Here is an example for caching your response for 365 days:
This is just an example, however.
Although this would be enough for ensuring your responses are cached in all regions available within the Full CDN, you should generally also include
maxage (used for client caches), so that all clients (e.g., browsers) also know for how long to cache your responses:
Cache-Control: s-maxage=31536000, maxage=0
As you can see above, the header is now instructing the client to expire any caches for the resource immediately. In general, we recommend this because it leverages Now's caches across the Full CDN instead of depending on the client's as well.
An important reason for this recommendation is that you have full control over purging Now's caches (unlike the client's), as you can read below.
By default, the cache for a response of your deployment is purged once the expiration timeout defined in
s-maxage is reached.
Furthermore, we also purge all caches related to a deployment when
now alias is used to assign the alias of the deployment to a different deployment, as this implies that new content needs to be served, thus requiring purging the caches.