EmDash CMS on Cloudflare

How the EmDash Cloudflare stack fits together

A visitor requests a page at your site's address. Cloudflare sends the request to the Worker running the application. The EmDash and Astro code can read CMS records from D1 and use media stored in R2 when producing the response. Editors use that same application to manage the content behind the public pages.

The diagram shows responsibilities, not a rule that every request must access both stores. A page may read an article record, while an image request needs the corresponding file. The application determines what is needed for a particular response.

Cloudflare bindings connect the running code to its configured resources. A database name in a project is not enough on its own: the deployed application must actually be connected to the intended database and storage. The official Cloudflare deployment documentation describes that wiring for a supported EmDash project.

What Cloudflare Workers does

Workers supplies the runtime for the built application. In ordinary terms, it is where code runs when the site needs to respond to a request. Public pages, CMS endpoints and the admin experience depend on that deployed application being configured correctly.

This differs from uploading a collection of finished HTML files to static hosting. EmDash needs a runtime for editing and current content. Astro's deployment adapter connects the application to its target environment, so building the project and deploying it are related but distinct steps.

A successful build tells you the project can be assembled. A successful production check tells you it can run with the actual services it needs. Useful checks include loading a public page, accessing the admin and confirming an authorised edit appears where expected.

Workers does not take ownership of the website's content or automatically decide its maintenance policy. The site operator still chooses software versions, application settings and deployment procedures. Cloudflare supplies the runtime; the project or managed platform supplies the operational decisions around it.

What D1 does for EmDash

D1 is the SQL database in the standard Cloudflare setup. EmDash's database holds the content model, entries, users, settings and plugin data. The database documentation separates those records from the media binaries stored elsewhere.

A content model describes the fields an editor can work with. An entry contains the information for one item, such as an article or service. Other records support the CMS itself. Together, they represent more than the text visible on the homepage.

Consider an uploaded photograph attached to a service entry. The database can record which media item that field refers to, while the file itself lives in storage. Exporting only page text would miss relationships and settings that make the website work.

For operation, this means the database needs an identified owner and a recovery plan. Keeping application source code in a repository is useful, but source code and live CMS records are different assets. Rebuilding the application does not reconstruct every edit made since the site's initial setup.

What R2 does for EmDash

R2 provides object storage for uploaded media in this deployment. Images and other files are stored as objects, rather than inside the application's source files or the CMS text fields. EmDash uses its storage integration to work with those files.

That separation matters during both normal publishing and recovery. An entry can exist in the database while its referenced image is missing from storage. Likewise, a bucket full of files is not a complete copy of the content model or the users who edit the site.

The official media-storage guide explicitly explains that database backups contain media metadata, not the stored files. An operator should account for the storage backend separately.

When evaluating a hosting arrangement, ask how uploaded media persists through an application release and what happens if a file needs restoring. Those questions concern data management, rather than the appearance of the media library. Having an upload button does not by itself answer them.

Where Astro fits

Astro is the framework used to build the public website. Routes, layouts and components decide how content appears. EmDash supplies the content system those pages use, along with the editor's admin experience. Cloudflare is the environment in which the resulting application runs.

These roles are easier to see through a page change. An editor changes an article in EmDash. The site's Astro implementation reads the relevant content and presents it using the chosen layout. Changing that layout is application work; correcting the article's wording is editorial work.

Our guide to EmDash CMS and Astro explains that boundary in more detail. It is especially useful if you are deciding whether to add a CMS to an existing Astro project or preparing a new theme.

Domains and HTTPS

A domain gives visitors a recognisable address for the application. DNS and hostname configuration connect that address to the intended deployment. HTTPS supplies the encrypted browser connection. These are hosting concerns around the website, alongside its CMS configuration.

EmDash does not independently configure every possible domain arrangement. A site may run at a provider address, a customer domain or a subdomain. Each arrangement needs the correct routing and public-site settings so links and requests refer to the intended website.

A managed platform such as DashHarbor can own the hosting side of that connection. Its committed launch service includes customer domains, subdomains and HTTPS. Website owners still need control of a domain they want to use and may need to make the requested DNS changes.

For an existing domain, plan the switch deliberately. Check where the website currently points and distinguish website routing from other records used for email or unrelated services. Connecting a website should not become an accidental change to everything else using the same domain.

Backups and recovery

A useful recovery plan considers the application, database and media together. Application code explains how the site works; database records hold the CMS state; media storage holds uploaded files. Protecting only one of those leaves an incomplete route back to a working website.

For example, restoring an article's database record without its accompanying photographs could produce a page with missing images. Restoring media without the content relationships may leave files present but unused. The aim is to recover a usable site, rather than merely produce a successful export command.

Operators should know what is included in a backup, where it is held and how restoration is checked. That does not imply every website needs the same process or retention schedule. The appropriate policy depends on the service and the value of its data.

DashHarbor's launch scope includes backups and recovery workflows around the managed site. This guide makes no claim about a particular retention period or restoration time. Those are explicit service commitments to review when choosing a host.

Updates and maintenance

EmDash is a software dependency within the application. Astro, adapters and other project dependencies also form part of the deployed site. Updating them is a controlled software change, with a build and deployment process, rather than a content edit.

Before releasing an update, an operator should check compatibility and the site's important workflows. Can visitors still reach pages? Can an editor sign in and publish? Does media still display? These checks connect maintenance to the way people actually use the website.

Changes to database structure deserve separate attention because live data persists beyond any one application release. A useful procedure identifies what changes, which version is being deployed and how to recover if the result is unsuitable.

Using managed infrastructure removes some server-administration tasks, but it does not remove application maintenance. DashHarbor's role is to handle supported platform updates and technical operation around customer websites, rather than make each owner maintain the deployment process.

Do I need my own Cloudflare account?

If you self-host on Cloudflare, you normally operate your own account and resources. You need the access required to deploy the application and manage its dependencies. Account ownership is therefore part of the operational decision, alongside the code and data.

With DashHarbor, the managed service is intended to abstract infrastructure operation from the website owner. Customers work with their website, dashboard and EmDash editor. They should not need to learn the individual hosting services simply to publish a routine content update.

That distinction describes the customer experience without assuming a particular account-transfer arrangement. If direct ownership of every underlying resource is essential to your project, discuss that requirement before choosing a managed service.

Does EmDash require Cloudflare?

No. EmDash supports Node.js deployment as well. The official Node.js guide describes a server-based setup, with supported database and media-storage options. It is a valid route for teams whose environment or expertise fits that model.

Cloudflare's Workers, D1 and R2 combination is a convenient way to understand this particular architecture, not a condition attached to the CMS. Compare the operational requirements of both paths in our guide to self-hosting EmDash.

Why DashHarbor uses Cloudflare

DashHarbor needs a repeatable hosting shape for provisioning and operating customer websites. The application, database and media services in this stack give the platform clear resources to prepare and manage. That fits a product in which customers choose a design and work with content.

The choice is about the managed platform's operating model. It does not establish that every EmDash project should make the same infrastructure decision, or that another deployment could not work well. A technically capable team may prefer Node.js for reasons specific to its own environment.

For a website owner, the practical question is whether the managed service covers the responsibilities they want to delegate. Understanding the stack helps make that decision without requiring them to become its operator.