CDN for Discourse, Concrete CMS, Kirby, Perch, and Kentico

A content delivery network can place static website files closer to visitors while reducing repeated asset requests to the origin. The right integration method, however, depends on how each platform generates URLs and manages files.

This guide compares practical CDN paths for Discourse, Concrete CMS, Kirby, Perch, and Xperience by Kentico. It serves as a central chooser and directs you to the detailed CDNsun integration tutorial for each platform.

If your project uses a more widely deployed CMS or commerce platform, see our companion guide to CDN integration for WordPress, Joomla, Drupal, and Magento.

Jump to a CDN integration tutorial

Why use a CDN with these platforms?

These five platforms cover very different projects, from community forums and small bespoke websites to enterprise digital experiences. Their CDN integrations nevertheless share the same basic objective: eligible static content is requested through a CDN Service Domain, while dynamic application requests remain on the origin.

Depending on the site, suitable content may include:

• CSS and JavaScript bundles
• Theme images, icons, fonts, and other frontend resources
• Public uploads and managed media when their storage path is included in the integration
• Versioned application assets that can be cached safely

Serving these files through a CDN can reduce the distance between visitors and cacheable content. It may also decrease repeated asset delivery from the origin and help pages behave more consistently for geographically distributed visitors.

A CDN does not automatically make every request cacheable. Personalized HTML, authenticated sessions, administration pages, dynamic routes, and other application-generated responses normally remain on the origin unless they are covered by a separately designed and tested caching policy.

Common prerequisites before setup

Before changing platform configuration or templates, prepare the CDN service and define exactly which content it should deliver.

1. Create the service. Follow the guide to create a CDN Static service with the website’s origin configured correctly.
2. Record the CDN Service Domain. This is the hostname that visitors use to retrieve CDN-delivered files. It is not the origin hostname.
3. Confirm HTTPS. Use an HTTPS CDN Service Domain on an HTTPS website to avoid mixed-content errors. Some platform settings require the scheme to be written explicitly.
4. Define the asset scope. Decide whether the integration covers theme resources, compiled application assets, public uploads, managed media, or a combination of these paths.
5. Check origin accessibility. The CDN must be able to retrieve eligible files from the configured origin without authentication failures, redirect loops, or restrictive access rules.
6. Plan cache updates. Use versioned filenames, query-string revisions, or cache purges when replacing files that may already be cached.
7. Capture a baseline. Load representative pages before the change and record their asset URLs, status codes, and browser-console state. This makes post-change verification easier.

It is usually safer to begin with clearly static resources and expand the scope only after confirming that the initial paths work correctly.

Five-platform CDN chooser

The versions below are tutorial-tested environments: verified baselines for the linked procedures, not permanent claims about the latest available releases.

For another set of CMS and business-platform integration paths, compare our guide to CDN setup for PrestaShop, Odoo, TYPO3, and Grav.

Discourse CDN setup overview

Best for: teams running a dedicated community or customer-support forum that want a native, application-level CDN asset setting.

Discourse has the most direct native path in this group. For a Docker-based deployment, the integration uses DISCOURSE_CDN_URL in the application’s app.yml configuration. The literal setting should contain the complete CDN URL, including the explicit https:// scheme and the CDN Service Domain.

After changing the configuration, the Discourse application container must be rebuilt so the new value is applied. This is an operational deployment step, so schedule it appropriately and retain a recoverable copy of the working configuration.

Once rebuilt, inspect a public forum page and confirm that eligible compiled assets use the CDN Service Domain. Forum topics, user sessions, administrative routes, and other dynamic application requests should not be assumed to move to the CDN merely because the asset setting is enabled.

Read the full Discourse CDN integration tutorial

Concrete CMS CDN setup overview

Best for: organizations that value editor-friendly page building but also have developers available to control theme and asset behavior precisely.

Concrete CMS requires a more selective integration because application assets, theme resources, and File Manager media do not all share one automatic URL-rewriting path. The tested approach combines Concrete CMS’s AssetList facilities with an environment variable and theme-level code.

Keeping the CDN Service Domain in an environment-specific value helps separate deployment configuration from template logic and makes it easier to use different hostnames across development, staging, and production. Theme code can then generate CDN URLs for the intended static resources.

Review the rendered HTML rather than assuming every asset is included: custom templates, packages, and manually written URLs may follow different code paths.

File Manager media needs separate attention. Uploads are connected to storage locations, and setting up CDN delivery for theme or registered application assets does not automatically cover File Manager files. If those files should use the CDN, configure and validate the relevant storage-location behavior as its own scope.

Read the full Concrete CMS CDN integration tutorial

Kirby CDN setup overview

Best for: developers building tailored flat-file websites who want explicit control over the boundary between public files and dynamic application routes.

Kirby gives developers direct control over how public asset and media URLs are constructed. The integration defines custom public URLs for eligible assets and media. This fits Kirby’s developer-led architecture: the site can keep its application and content-processing routes on the origin while producing CDN URLs for selected public files.

Map each public CDN URL to a path that the configured origin can actually serve. A rewritten hostname is not enough if the resulting request points to a nonexistent origin path or if access controls prevent the CDN from retrieving the file.

Kirby’s dynamic routes should remain on the origin unless a separate caching design has been evaluated. This distinction is especially important for panel access, form handlers, search, session-aware behavior, and templates that generate visitor-specific responses.

Read the full Kirby CDN integration tutorial

Perch CDN setup overview

Best for: small, bespoke websites that already have a frontend and need focused content editing without replacing the site’s underlying structure.

This guide covers Perch 3.2. It does not combine Perch with Perch Runway, which has a broader application model and may require different deployment decisions.

Perch separates several asset concerns. The PERCH_RESPATH setting controls the public path for managed Perch resources. Assets written directly into the existing frontend templates need a separate CDN base URL so their generated paths use the CDN Service Domain.

Sites using Resource Buckets may also need the bucket’s web_path adjusted for CDN delivery. Treat this as an optional scope rather than assuming every installation uses the same storage arrangement.

Test managed resources, template assets, and bucket-backed files independently. A successful request for one group does not prove that the other paths have been rewritten or that they map to reachable files on the origin.

Read the full Perch CDN integration tutorial

Xperience by Kentico CDN setup overview

Best for: enterprise and multichannel teams that need structured content and an application-level integration pattern within a larger digital experience architecture.

Xperience projects can centralize the CDN Service Domain in application configuration and use a helper when rendering static files. The tutorial-tested approach stores the CDN BaseUrl in appsettings. A Razor helper then combines that value with eligible static asset paths when generating frontend markup.

Central configuration avoids scattering a deployment-specific hostname across multiple views. Keep the origin paths aligned with the URLs produced by the helper, then verify representative stylesheets, scripts, images, and fonts in the rendered page source and browser network panel.

Content Hub assets are an optional, separately validated scope. They should not be treated as automatically covered by the static-asset helper. Confirm how those files are published, transformed, protected, and addressed before routing their URLs through the CDN.

Read the full Xperience by Kentico CDN integration tutorial

Verification and troubleshooting basics

Verification should confirm both sides of the delivery path: the page must generate the expected CDN URL, and the CDN must be able to retrieve the corresponding file from the origin. Start with an end-to-end check before diagnosing individual symptoms.

1. Open a representative public page. Choose a page that loads the asset types included in the integration.
2. Inspect the rendered HTML. Confirm that eligible asset URLs use the CDN Service Domain with the expected HTTPS scheme and path.
3. Use the browser network panel. Reload the page and check status codes, response headers, redirects, content types, and transferred files.
4. Check the browser console. Look for mixed-content warnings, blocked fonts, cross-origin errors, JavaScript failures, and missing source maps.
5. Test the origin mapping. If a CDN URL returns an error, confirm that its path resolves to the intended file on the configured origin.
6. Repeat on multiple page types. Test pages with different themes, templates, uploads, or application bundles rather than relying on the home page alone.
7. Check authenticated areas separately. Confirm that sign-in, editing, administration, and personalized routes still behave as intended on the origin.

Browser developer tools can confirm that the hostname changed, but a complete check should also verify that the delivered file is current and has the correct MIME type and access policy.

Assets still use the origin hostname

Confirm that the platform configuration was applied in the correct environment. Clear application or template caches where relevant, and rebuild or redeploy when the platform requires it. Also check for hard-coded URLs that bypass the platform’s asset helpers.

The CDN returns 404 responses

Compare the path after the CDN Service Domain with the path available on the origin. Common causes include an incorrect origin base path, a duplicated directory segment, or a rewrite that produces a public URL for a file the origin does not expose.

The origin returns 403 responses

Review authentication rules, firewall restrictions, hotlink protection, and storage permissions. The CDN needs permission to retrieve public files included in the integration.

The browser reports mixed content

Use an HTTPS CDN Service Domain and ensure the platform’s literal CDN URL includes https:// where required. Check templates and stored content for older hard-coded HTTP URLs.

Fonts or scripts are blocked

Cross-origin policies may need attention when assets move to another hostname. Verify CORS response headers, font MIME types, Content Security Policy directives, and any integrity attributes used by the page.

Visitors receive an older file

Change the asset version or filename when supported, or purge the affected CDN cache entry. Confirm that the origin itself serves the new file before troubleshooting the edge response.

Dynamic or administrative pages behave incorrectly

Recheck the integration scope. Dynamic routes, personalized HTML, authenticated content, and administration pages should not be presumed cacheable. Keep them on the origin unless a deliberate policy has been designed and tested for those responses.

Which platform should you choose?

The CDN integration matters, but it should not outweigh the platform’s underlying fit for the project.

• Choose Discourse when the website’s primary purpose is structured community discussion, member support, or a searchable forum. Its native CDN setting also provides the shortest integration path in this group.
• Choose Concrete CMS when editors need direct page-building workflows and the development team is comfortable controlling several asset and storage paths.
• Choose Kirby when developers want a lightweight flat-file foundation, custom content models, and explicit control over public URL generation.
• Choose Perch when an existing bespoke frontend needs manageable content regions without a full platform replacement. Keep the decision specific to Perch rather than assuming Perch Runway uses the same architecture.
• Choose Xperience by Kentico when the project requires enterprise content operations, multichannel delivery, and an integration-oriented CMS-DXP application.

If your shortlist includes other developer-led or commerce-oriented systems, our comparison of CDN integration for Shopware, MODX, Craft CMS, and OpenCart provides four additional implementation patterns.

Whichever platform you select, define the CDN scope before deployment. A narrow, verified integration for static assets is usually easier to operate than an ambiguous setup that unintentionally includes dynamic application traffic.

Open the complete setup tutorials

• Configure CDN delivery for Discourse
• Configure CDN delivery for Concrete CMS
• Configure CDN delivery for Kirby
• Configure CDN delivery for Perch
• Configure CDN delivery for Xperience by Kentico

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