CDN for CakePHP, Phalcon, and Laminas

A content delivery network can deliver eligible static files closer to visitors and reduce repeated asset delivery from the application origin. The implementation path depends on how each PHP framework generates URLs for stylesheets, JavaScript, images, and other public files.

This guide compares CDN setup for CakePHP, Phalcon, and the Laminas Project. Laminas is the open-source successor to Zend Framework.

Use this page as a chooser, then follow the matching CDNsun tutorial for the complete procedure. For four other application frameworks, see CDN for Laravel, Symfony, Ruby on Rails, and CodeIgniter.

Jump to a CDN integration tutorial

Why use a CDN with these PHP frameworks?

All three integration paths have the same basic objective: framework helpers or asset services generate URLs on a CDN Service Domain for eligible public files, while dynamic application traffic stays on the origin.

Depending on the application, suitable files may include:

• CSS and JavaScript files
• Images, icons, and fonts
• Other publicly reachable static resources whose paths are generated through the configured helper or service

CDN delivery can reduce delivery distance and repeat origin requests for cacheable files. The observed result depends on visitor location, cache behavior, origin performance, file size, and page composition, so teams should capture a baseline and verify the change under representative conditions.

Keep controllers, authentication, form targets, API endpoints, administration routes, personalized responses, and other dynamic requests on the application origin unless a separate delivery policy has been designed and tested for them.

For similar patterns across community and content platforms, read CDN for Discourse, Concrete CMS, Kirby, Perch, and Kentico.

Common prerequisites before setup

Prepare the service, origin mapping, and validation plan before changing 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 that will serve eligible static files, not the hostname used for dynamic application routes.
3. Use the complete HTTPS URL. Include the scheme wherever the framework configuration expects a full base URL.
4. Define the static scope. Decide which CSS, JavaScript, images, fonts, and other public files should use the CDN while keeping dynamic URLs on the origin.
5. Verify origin paths. Every generated CDN path must map to a publicly retrievable file at the configured origin.
6. Separate deployment values from templates. Keep the CDN hostname in environment-backed configuration where the documented method supports it.
7. Capture a baseline. Record representative URLs, response status codes, browser-console output, and rendered application behavior before the change.
8. Start narrowly. Validate one representative file from each intended asset group before expanding the integration.

Do not add an assumed build process. The CakePHP and Phalcon tutorials do not specify a build or cache command; the Laminas procedure explicitly requires its configuration cache to be cleared after changes. If your project uses a CMS as well as a custom application layer, CDN for WordPress, Joomla, Drupal, and Magento covers four different platform paths.

CakePHP, Phalcon, and Laminas CDN chooser

The version column lists tutorial-tested environments or project scope. It is a record of the documented baseline for each procedure, not a release recommendation.

To compare four more application and business-platform implementations, continue with CDN for PrestaShop, Odoo, TYPO3, and Grav.

CakePHP CDN setup overview

Best for: CakePHP applications using the native HtmlHelper and conventional webroot/css, webroot/js, and webroot/img directories.

The tutorial-tested environment is CakePHP 5.4.1. The documented setup stores the complete HTTPS CDN Service Domain in CDN_BASE_URL and removes any trailing slash before using the value in config/app.php.

Inside the existing App configuration, imageBaseUrl, cssBaseUrl, and jsBaseUrl receive the normalized CDN value plus /img/, /css/, and /js/, respectively. When the environment value is empty, the settings retain their local img/, css/, and js/ fallbacks.

Views then generate asset URLs with $this->Html->image(), $this->Html->css(), and $this->Html->script(). These helper-generated static URLs use the configured CDN domain, while application routes and other dynamic URLs remain unchanged. Literal static paths in existing templates must be converted to the matching helper; the procedure does not perform automatic rewriting.

Read the full CakePHP CDN integration tutorial

Phalcon CDN setup overview

Best for: Phalcon applications using the native URL service and Assets Manager for public static files.

The tutorial-tested environment is Phalcon 5.16.0. Its key distinction is the separation between dynamic and static URL bases in the shared URL service. setBaseUri('/') keeps application routes on the origin, while setStaticBaseUri() uses the normalized CDN_BASE_URL value for static files. If the environment variable is empty, the static base falls back to /.

Local CSS and JavaScript paths remain under the public document root and are registered with the Assets Manager. Its output methods generate their public URLs through the registered URL service. Images and other public static paths use getStatic(), which applies the static base without changing controller routes.

Remaining literal paths in views must be changed to getStatic() or the Assets Manager. Do not apply the static base URI to form actions, authentication URLs, API endpoints, or other dynamic requests.

Read the full Phalcon CDN integration tutorial

Laminas CDN setup overview

Best for: Laminas MVC projects whose teams want a centralized, environment-backed helper for public asset URLs.

The tutorial-tested environments are Laminas MVC Skeleton 2.4.0 and laminas-mvc 3.8.0. Laminas is the open-source continuation and successor of Zend Framework, but the documented Laminas setup uses its own helper-and-factory pattern.

The procedure stores the complete HTTPS CDN Service Domain in CDN_BASE_URL, removes the trailing slash, and exposes the result as cdn.base_url in config/autoload/global.php. A custom CdnAsset view helper prefixes public asset paths with that value. When it is empty, the helper returns an origin-relative path instead.

A CdnAssetFactory reads the central configuration and supplies it to the helper. The application registers the cdnAsset alias and factory in the view_helpers section of module/Application/config/module.config.php. Static basePath() calls and literal asset paths in views are then replaced with cdnAsset(). Routes, forms, API requests, and other dynamic links stay on the origin.

After changing the configuration or helper registration, run php bin/clear-config-cache.php. This explicit cache step is part of the documented Laminas procedure.

Read the full Laminas CDN integration tutorial

Legacy Zend Framework 1 context

Zend Framework 1 is a discontinued predecessor of Laminas and no longer receives official Zend updates. The zf1-future project is a community continuation, not an official current Zend release. New applications and migrated projects should use the Laminas path without assuming that migration or CDN configuration is automatic. Maintainers of existing ZF1 applications can consult the Zend Framework CDN integration tutorial for the preserved legacy method.

Verification and troubleshooting basics

A complete check must confirm both sides of the delivery path: the framework should render the intended CDN URL, and that URL should resolve to the corresponding public file on the origin.

1. Open a representative public page. Choose a page that loads each asset group included in the integration.
2. Inspect the rendered HTML. Confirm that intended static files use the HTTPS CDN Service Domain.
3. Use the browser network panel. Check status codes, redirects, response headers, MIME types, and transferred files.
4. Check the browser console. Look for mixed content, CORS errors, Content Security Policy violations, blocked fonts or scripts, and JavaScript failures.
5. Compare CDN and origin paths. Match each CDN URL path to the corresponding publicly reachable path on the configured origin.
6. Test multiple application states. Check several layouts and views, including authenticated and unauthenticated behavior.
7. Recheck configuration and cache state. Confirm that the intended environment is active and apply only the cache step required by the relevant framework procedure.

Assets still use the origin hostname

Check the selected environment and look for literal paths that bypass the configured helper or service. In CakePHP, confirm that the correct HtmlHelper method generates each URL. In Phalcon, verify that views use the shared URL service, getStatic(), or the Assets Manager. In Laminas, verify the helper alias and factory registration, then clear the configuration cache.

The CDN returns 404 responses

Compare the generated path with the actual public origin file. Pay particular attention to CakePHP’s /img/, /css/, and /js/ paths, Phalcon’s public document root, and paths passed to the Laminas helper.

The origin returns 403 responses

Review public-file permissions and origin access rules. Changing the hostname does not bypass authentication, filesystem permissions, firewall policy, or other access controls.

The browser reports mixed content

Use the complete HTTPS CDN URL and locate old hard-coded HTTP references in templates, configuration, and stored content.

Fonts or scripts are blocked

Review CORS response headers, MIME types, Content Security Policy directives, and integrity attributes according to the application’s actual requirements. A special cross-origin step should not be assumed for every asset or every one of these integrations.

Visitors receive an older asset

First confirm that the origin serves the new file. Then change its version or filename, or purge the affected CDN object. These three methods do not establish a shared built-in fingerprinting process.

Dynamic routes behave incorrectly

Recheck helper and service use. Controllers, routes, forms, authentication, APIs, administration areas, and personalized responses should remain on the origin.

Which framework should you choose?

CDN setup convenience is one implementation concern, not a substitute for selecting the right framework for the application, existing codebase, deployment model, and team expertise.

• Choose CakePHP’s path when the project uses native HtmlHelper methods and conventional asset directories under webroot.
• Choose Phalcon’s path when the project already uses the native URL service and Assets Manager, with a deliberate split between dynamic and static base URIs.
• Choose Laminas’s path for maintained Laminas MVC projects that can register a reusable view helper and factory. The preserved ZF1 tutorial is only for existing legacy applications; new or migrated work should follow the Laminas path.

For additional developer-led and commerce-oriented options, see CDN for Shopware, MODX, Craft CMS, and OpenCart.

Whichever framework fits the application, keep the first deployment narrow. A clearly defined static-asset scope is easier to verify and operate than a configuration that unintentionally redirects dynamic traffic.

Open the complete setup tutorials

• Configure CDN delivery for CakePHP
• Configure CDN delivery for Phalcon
• Configure CDN delivery for Laminas
• Configure CDN delivery for Zend Framework

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.