Runtime asset policy

Approved CDNs

Approved CDN policy keeps runtime imports predictable and safe. The goal is to preserve broad creator flexibility without opening dangerous host lanes.

Host allowlist policy for reliable and safe runtime asset loading.

Implementation focus

Consult this page whenever you add third-party scripts, assets, or external package delivery sources.

Expected outcomes

How to use this list

The approved CDN page is a compatibility map, not a permission slip to load arbitrary executable code. Script trust, passive asset loading, font loading, and backend connect origins are separate lanes with separate risk.

For production work, prefer npm imports and platform-managed dependency resolution where possible. Use CDN scripts only when the project shape truly requires HTML-style loading.

  • Executable script origins are narrower than image, media, or font origins.
  • Studio-only compatibility does not imply published runtime trust.
  • Passive storage-backed asset origins should not become script or API trust by accident.

Trust lanes

A host can be safe for one kind of asset and unsafe for another. Font stylesheet origins, font file origins, image hosts, media hosts, API connect hosts, and executable script hosts are reviewed differently because they create different browser and platform risks.

When a dependency does not fit the published runtime script list, the safer answer is usually to package it through the normal build/dependency path instead of broadening script-src. That keeps runtime behavior repeatable and avoids giving every project a new executable origin.

  • Use the script list only for browser-executed CDN scripts in published HTML vibes.
  • Use passive image and media compatibility lists for display assets, not code loading.
  • Use connect origins for network calls, and keep credential-backed calls in Pulses.
  • Request new hosts with the intended asset type so the review can stay lane-specific.

Example and read next

Example: an HTML demo imports a script from a CDN. Check the published runtime script list before shipping executable dependencies, and prefer npm imports when a package can be mirrored and pinned by Vibecodr.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

  • Read next: Secrets & APIs (/docs/secrets)
  • Read next: Embeds (/docs/embeds)
  • Read next: Automation Safety (/docs/automation-safety)
  • Read next: Vibes & Pulses (/docs/vibes-pulses)

Related documentation

  • /docs/secrets
  • /docs/embeds
  • /docs/automation-safety
  • /docs/vibes-pulses

    • Published runtime script CDNs

    Used by `<script src="...">` in shipped HTML vibes.

    Studio-only compatibility

    These are allowed for Studio preview compatibility, not as part of the published runtime script trust boundary.

    Auth and identity connect origins

    These hosts are the documented first-class providers for app-network integrations. They are not the browser runtime's full egress boundary: in allow-https mode, vibes still keep connect-src open to https and wss.

    Backend platform connect origins

    Data service connect origins

    Common public API origins

    Font stylesheet origins

    Font file origins

    Known image compatibility origins

    These are common/tested passive image hosts. They are not the full runtime passive-image boundary: in allow-https mode, ordinary HTTPS image hosts are permitted while executable script trust stays curated separately.

    Known media compatibility origins

    These are common/tested passive media hosts. They are not the full runtime passive-media boundary: in allow-https mode, ordinary HTTPS media hosts are permitted while script trust remains narrow.

    Passive storage-backed asset origins

    These hosts are passive-only. They should not be treated as general script or connect trust.

    Practical guidance