CDN types: Standard vs. Pro

Locize offers two different Content Delivery Network (CDN) infrastructures to serve your translation files. You can choose the one that best fits your project's security, caching, and feature requirements.

Standard CDN (BunnyCDN)

The Standard CDN is the new default for all newly created projects. It is powered by BunnyCDN and provides a high-performance, cost-effective solution for most public-facing applications.

Key Characteristics

• Public Access Only: Translation files published to the Standard CDN are publicly accessible. You cannot restrict access using API keys or private publishing.
• Fixed Caching Policy: The caching duration (TTL) is fixed at 1 hour. You cannot define a custom Cache-Control max-age.
• No Native Published Namespace History: This CDN type does not support the Published Namespace History feature.

Development Workarounds for Caching

Since the default cache is 1 hour, you might see old translations during active development. You can bypass the cache using the following methods:

1. Using Query Parameters

Append ?cache=no to your fetch URL to force a fresh download:

https://api.lite.locize.app/{{projectId}}/{{version}}/{{lng}}/{{ns}}?cache=no

2. Using i18next-locize-backend

If you are using the official backend plugin, set the reloadInterval or noCache option:

import i18next from "i18next";
import Locize from "i18next-locize-backend";
i18next.use(Locize).init({
  backend: {
    projectId: "[PROJECTID]",
    cdnType: "standard",
    noCache: true // <-- set strictly for development to bypass cache
  },
  fallbackLng: 'en',
  supportedLngs: ['en', 'de']
});
// Alternative configuration:
// If 'debug: true' is set in i18next, it will also bypass the cache automatically
// even if noCache is not explicitly set.
/*
i18next.use(Locize).init({
  debug: true,
  backend: {
    projectId: "[PROJECTID]",
    cdnType: "standard"
  },
  // ... other options
});
*/

Pro CDN (AWS CloudFront)

The Pro CDN is the robust infrastructure that Locize has used since the beginning. It is based on Amazon CloudFront and is designed for projects requiring advanced control, privacy, and safety nets.

Key Characteristics

• Private Downloads: Supports Private Publishing. You can restrict access to your translation files so they can only be downloaded with a valid API key or Personal Access Token.
• Custom Caching: You can fully configure the Cache-Control max-age per version to optimize for latency or freshness according to your specific needs.
• Published Namespace Backups: Automatically retains backups of your namespaces. This allows you to roll back to previous versions if a mistake is published.

Which one should I choose?

Choose Standard if:

• Your project is a smaller public website, landing page, or open-source project.
• Your translation data is not sensitive.
• You do not need to retain historical backups of translation files within the CDN.
• A 1-hour cache time is acceptable for your production environment.

Choose Pro if:

• Security is a priority: You need to ensure your translation files are not publicly downloadable (e.g., internal enterprise tools, unreleased products).
• Risk Management: You rely on Published Namespace Backups to restore data in case of accidental overwrites.
• Performance Tuning: You need granular control over browser caching (e.g., setting long cache times for production efficiency).

Cost consideration for private downloads

Private namespace downloads are billed at a higher rate than standard or pro downloads. At high request volumes, the cost can add up quickly. If your application makes frequent authenticated requests (e.g. per-tenant namespace delivery at scale), consider whether standard (public) CDN delivery would work for your use case instead. You can review the current rates on the pricing page.

Changing your CDN Type

You can switch your project between Standard and Pro at any time in your project settings. During your trial you can change it on the "API, CDN, NOTIFICATIONS" tab:

And when subscribed you can change it on the "PLAN, ADDONS, ..." tab:

Depending on your integration you may need to change the cdnType option in your tools (CLI, i18next-locize-backend, locizify, locizer, etc.) or change the API endpoint.

What happens when you switch the CDN type

The Standard CDN (api.lite.locize.app) and Pro CDN (api.locize.app) are two completely separate infrastructures. Each project's published content lives on whichever CDN the project is currently set to, never both at once.

This is why, before switching, requests to the "other" CDN's endpoint will return 404. Example: if your project is on Pro CDN, calling https://api.lite.locize.app/{projectId}/... returns 404 because nothing has ever been published there.

When you change the CDN type in your project settings:

1. All versions with auto-publish enabled are automatically republished to the new CDN. Wait a few moments for this to complete.
2. Versions without auto-publish are NOT republished automatically. You'll need to trigger a manual publish for those after switching, otherwise their content won't appear on the new CDN.
3. The old CDN's content is NOT deleted. It stays in place and simply stops receiving new publishes. This means both the old and new CDN endpoints will serve content during the transition window.

Zero-downtime migration (Pro → Standard or Standard → Pro)

Because the old CDN keeps serving its existing content after the switch, you can migrate without any downtime:

1. Switch the CDN type in your project settings. The system auto-republishes your autoPublish versions to the new CDN.
2. Verify the new CDN endpoint returns your content (e.g. https://api.lite.locize.app/{projectId}/{version}/{language}/{namespace} for Standard).
3. Trigger a manual publish for any non-autoPublish versions, if applicable.
4. Deploy your application change to point to the new CDN: update the cdnType option in your tools (i18next-locize-backend, locize-cli, locizify, locizer) or use the new endpoint directly.
5. Roll your traffic over. During this window, the old CDN endpoint still serves the previously published content, so the rollout can be gradual.
6. No cleanup needed on the old CDN; its content simply becomes stale and unused.

Note for Pro → Standard: If your project uses private publishing on any version, that version cannot be published on the Standard CDN; the publish will be refused. Standard CDN supports public downloads only.