CDN for Laravel, Symfony, Ruby on Rails, and CodeIgniter

A content delivery network can deliver eligible static files closer to visitors and reduce repeated asset delivery from the origin. The configuration path depends on how a framework generates, builds, and deploys asset URLs.

This guide compares CDN setup paths for Laravel, Symfony, Ruby on Rails, and CodeIgniter. It serves as a central chooser, with direct links to detailed, verified CDNsun tutorials for each framework.

For other application and content platforms, see our companion guides to CDN for Discourse, Concrete CMS, Kirby, Perch, and Kentico and CDN integration for WordPress, Joomla, Drupal, and Magento.

Jump to a CDN integration tutorial

Why use a CDN with these frameworks?

All four integrations share one objective: framework helpers or asset tooling generate URLs on the CDN Service Domain for eligible static files, while dynamic application traffic remains on the framework origin.

Depending on the application and its configuration, suitable files may include:

• Compiled or mapped CSS and JavaScript
• Images, icons, fonts, and other public assets
• Framework-managed asset-pipeline files
• Specifically configured public files, uploads, or media

CDN delivery can reduce the distance to cacheable files and decrease repeat asset delivery from the origin. The result depends on factors such as visitor location, cache behavior, origin performance, file size, and page composition, so the change should be measured rather than assumed.

Changing asset URLs does not move controller actions, authentication, form targets, administration routes, personalized responses, or other dynamic behavior to the CDN. Those requests remain on the application origin unless they are covered by a separate, deliberately tested delivery design.

Common prerequisites before setup

Prepare the delivery path and define its scope before editing framework configuration.

1. Create the service. Follow the guide to create a CDN Static service and configure the application origin correctly.
2. Record the CDN Service Domain. This is the hostname used for CDN-delivered assets, not the application’s origin hostname.
3. Confirm HTTPS. Use the complete HTTPS CDN URL wherever a framework setting expects a scheme and hostname.
4. Define the asset scope. Separate compiled assets, files under the public directory, and uploaded or media storage. They may require different URL-generation paths.
5. Confirm origin paths. The path generated on the CDN hostname must resolve to the same public file at the configured origin.
6. Plan the production build or deployment step. The verified Laravel, Symfony, and Rails paths include framework-specific build or compilation commands. The CodeIgniter method requires view URL updates but does not specify an asset compilation command.
7. Plan cross-origin delivery. Review the CDNsun CORS configuration guide. The Laravel, Symfony, and Rails tutorials require relevant cross-origin setup when their production JavaScript modules load from another domain.
8. Capture a baseline. Record representative asset URLs, response status, browser-console state, and application behavior before changing configuration.

Begin with clearly static resources. Expand the scope only after the initial paths have been validated.

Four-framework CDN chooser

The versions below are tutorial-tested environments: verified baselines for the linked procedures, not claims about the current or only supported releases.

For four more platform-specific implementation patterns, compare our guide to CDN setup for PrestaShop, Odoo, TYPO3, and Grav.

Laravel CDN setup overview

Best for: Laravel applications that want native handling for Vite entry points, public assets, and public-disk files while retaining normal application routes on the Laravel origin.

The tutorial-tested environment is Laravel 13.24.0 with Vite 8.2.1. Its primary asset setting is ASSET_URL, which prefixes URLs generated by Laravel’s asset() helper and its production Vite integration.

Files on Laravel’s public filesystem use a separate URL setting. FILESYSTEM_PUBLIC_URL ends in /storage and supplies the URL for the existing public disk configuration. Calls such as Storage::disk('public')->url() then return the configured CDN path. If the public storage link does not already exist, php artisan storage:link connects public/storage to storage/app/public.

Blade templates should use @vite for compiled entry points, asset() for public-directory files, and Storage::url() or the verified public-disk call for public filesystem files. Vite does not rewrite absolute asset URLs, so files intended for CDN delivery should use Vite-managed imports or Laravel URL helpers.

During production deployment, run npm run build to build the Vite assets and php artisan config:cache to rebuild Laravel’s configuration cache. Keep application routes, form actions, and other dynamic URLs on the Laravel domain.

Read the full Laravel CDN integration tutorial

Symfony CDN setup overview

Best for: Symfony applications using AssetMapper, Twig, and the Asset component for framework-managed public asset URLs.

The tutorial-tested environment is Symfony 7.4.16 with AssetMapper 7.4.15. The verified path stores the complete HTTPS CDN Service Domain in CDN_BASE_URL and applies it through framework.assets.base_urls.

The default asset package places the CDN domain on URLs generated by Twig’s asset() function. It also applies to AssetMapper’s import map, stylesheet links, module preloads, and JavaScript entrypoint URLs. A named media package can optionally provide a separate base path for files under public/media/; it does not change application routes.

Mapped files use logical paths, and AssetMapper adds content hashes to their public filenames. For production, run php bin/console asset-map:compile, then deploy the resulting public/assets/ directory so the CDN can retrieve those same paths from the origin. Cross-origin AssetMapper JavaScript modules also require the relevant CORS setup described in the common prerequisites.

Read the full Symfony CDN integration tutorial

Ruby on Rails CDN setup overview

Best for: Rails production applications that use Rails asset helpers and Propshaft-managed, digest-stamped assets.

The tutorial-tested environment is Ruby on Rails 8.1.3.1 with Propshaft 1.3.2. The verified configuration stores the complete HTTPS CDN URL in CDN_HOST and assigns it to config.asset_host in config/environments/production.rb.

Rails applies this host to URLs generated by its asset helpers. Literal paths such as /images/logo.svg bypass the configured host. In production, the helpers can generate digest-stamped filenames: when an asset’s content changes, its digest and filename change, which makes long-lived caching appropriate for those fingerprinted files. The same assumption should not be extended to non-fingerprinted files.

Run RAILS_ENV=production bin/rails assets:precompile during deployment and deploy public/assets/ with the application. Controllers and dynamic responses remain on the Rails origin.

Active Storage is a separate scope. config.asset_host applies to asset-pipeline files, not uploaded attachments. If attachments must use a CDN, follow the official Rails Active Storage CDN guidance and validate that path independently.

Read the full Ruby on Rails CDN integration tutorial

CodeIgniter CDN setup overview

Best for: CodeIgniter 4 applications whose team is comfortable maintaining a small environment-backed helper for public asset URLs.

The tutorial-tested environment is CodeIgniter 4.7.4. The verified path adds the complete HTTPS CDN Service Domain to cdn.baseURL in .env, while app.baseURL remains set to the public application URL.

A custom cdn_url() helper joins the configured CDN domain to a static path. When the CDN value is empty, it falls back to the application’s base URL, allowing the same views to work without a hard-coded asset domain. The helper is added to app/Config/Autoload.php without replacing any existing helper entries.

Static files remain under public/, and view references pass paths relative to that directory. Existing static references must be updated to call cdn_url(); this method does not perform automatic site-wide URL rewriting. Do not use the helper for controller routes, form actions, authentication URLs, or other dynamic application requests.

Read the full CodeIgniter CDN integration tutorial

Verification and troubleshooting basics

Verification must confirm both sides of the path: the framework should generate the intended CDN URL, and the CDN should retrieve the corresponding file from the origin.

1. Open a representative public page. Choose a page that exercises the configured asset groups.
2. Inspect the rendered HTML. Confirm that eligible assets use the HTTPS CDN Service Domain.
3. Use the browser network panel. Check status codes, redirects, content type, response headers, and transferred files.
4. Check the browser console. Look for mixed content, cross-origin module errors, blocked fonts, Content Security Policy issues, and JavaScript failures.
5. Compare paths. Match each CDN path to the corresponding public path on the configured origin.
6. Check build output. Confirm that the deployed Laravel Vite output, Symfony public/assets/, or Rails public/assets/ exists, as applicable.
7. Test multiple application states. Check several layouts and views, as well as authenticated and unauthenticated behavior.
8. Verify separately scoped files. Test Laravel public-disk files, Symfony named-package media, or Rails Active Storage attachments independently when they are included.

Assets still use the origin hostname

Check the environment configuration, production environment, configuration cache, and required build or deployment step. Look for hard-coded paths that bypass framework helpers, including absolute Vite asset URLs in Laravel, literal asset paths in Rails, or CodeIgniter views that have not been converted to cdn_url().

The CDN returns 404 responses

Compare the CDN URL path with the public file path at the configured origin. For Laravel public-disk files, confirm that the storage link exists. For Symfony and Rails, confirm that the compiled public/assets/ directory was deployed.

The origin returns 403 responses

Review public-file permissions and origin access rules. A CDN hostname does not override authentication, storage permissions, or other access controls.

The browser reports mixed content

Use an HTTPS CDN Service Domain and check templates, environment configuration, and stored content for older hard-coded HTTP URLs.

Fonts or JavaScript modules are blocked

Review CORS response headers, font MIME types, Content Security Policy directives, and any integrity attributes used by the page. Apply a cross-origin policy that matches the application’s actual asset and security requirements.

Visitors receive an older asset

Prefer framework-generated hashes or digest filenames where the verified toolchain provides them. For other files, update the asset version or filename, or purge the affected CDN object after confirming that the origin serves the new revision.

Uploads or media still use the origin

The primary asset setting may not cover uploaded content. Laravel public-disk files use separate filesystem URL configuration, Symfony can use an optional named package for a public media path, Rails Active Storage needs a separate delivery path, and CodeIgniter’s helper affects only references that call it.

Dynamic routes behave incorrectly

Recheck helper usage and integration scope. Application routes, authentication, forms, administration, and personalized responses should remain on the origin unless a separate caching design has been deliberately implemented and tested.

Which framework should you choose?

CDN integration matters, but it should not outweigh the framework’s underlying fit for the application. Choose based on application requirements, language and ecosystem, the existing codebase, deployment model, and team expertise.

• Choose Laravel’s path when the project already uses Laravel’s Vite integration, asset() helpers, and/or the public filesystem disk.
• Choose Symfony’s path when the application uses AssetMapper and Twig asset packages, with optional named packages for distinct public paths.
• Choose Rails’ path when production assets are generated through Rails helpers and Propshaft. Plan Active Storage separately if attachments must use the CDN.
• Choose CodeIgniter’s path when the application serves files from public/ and the team can consistently use a custom helper across its views.

If your shortlist includes other developer-led or commerce-oriented systems, see our guide to CDN integration for Shopware, MODX, Craft CMS, and OpenCart.

Whichever framework you use, a narrow, verified static-asset integration is safer to operate than an ambiguous configuration that includes dynamic application traffic.

Open the complete setup tutorials

• Configure CDN delivery for Laravel
• Configure CDN delivery for Symfony
• Configure CDN delivery for Ruby on Rails
• Configure CDN delivery for CodeIgniter

Choose the tutorial that matches your framework, create the CDN Static service, and verify each asset group before expanding the integration. To test static content delivery with CDNsun, Start a free 15-day trial.