Move your site to a hosting provider

Once the initial build of your site is complete on your computer, making it live (or collaborating with your team) requires a web server at a hosting provider. This page covers picking a provider and moving your site out of your local DDEV environment so others can access it too.

Goal

Your site running at a hosting provider, where visitors can reach it and teammates can collaborate on it. Most hosting providers have the technical specifications required for hosting Drupal CMS.

Prerequisites

• A site built locally with DDEV; see Install Drupal CMS.

Steps

Pick a hosting provider

Drupal CMS works with a variety of hosting providers. It runs on commonly used open source software, so you have plenty of options. Check the Drupal 11 system requirements for the recommended server software and versions.

If you already work with a hosting provider, chances are good they can accommodate your Drupal CMS site; ask their support team if you are not sure. If you don’t have one, Drupal.org maintains a list of hosting providers who have demonstrated expertise in Drupal and a commitment to supporting the Drupal code and community.

The remaining steps depend on your hosting provider. Read your provider’s documentation for specific instructions on transferring files and importing a database.

Move the parts of your site

When you first publish your site, you move it from your computer to the web-based hosting provider. Account for each of these:

• Code: the PHP, HTML, CSS, and JavaScript that make up your site, stored as files in your Drupal CMS project directory. Hosts that support Composer expect the project in Git without the vendor/, web/core/, web/modules/contrib/, web/themes/contrib/, and web/sites/default/files/ directories, and run composer install --no-dev on the server to rebuild them. On a host without Composer, copy the whole project directory, including vendor/.
• Content: everything you and your team added that you want published on the live site:
  • Database: content entered into the database, like the text of a blog post or a review. Export it with ddev export-db.
  • Files: images, videos, and other documents uploaded while authoring content, found in the web/sites/default/files/ directory.
• Settings: the files in web/sites/default/ (for example, settings.php) contain environment-specific settings. Set them for the live server, not the DDEV values: the database connection, a unique $settings['hash_salt'], and $settings['trusted_host_patterns'] for your domain. The security checklist covers trusted host patterns.
• Configuration: content types, views, site-wide settings, and the other information you provided that determines how your site functions. Depending on your hosting situation, this is stored in the database or as YAML files in the project’s code base.

Switch content work to the live site

Once your site has been moved to the hosting provider, the new live, public-facing site is the official place for content updates. Any content changes on your local DDEV-powered site are visible only to you. Make content additions and updates on the live site, and invite your team to collaborate there.

Caution

Exporting the database from DDEV and moving it to the provider is a one-time process. Once the site is live, don’t overwrite the hosting provider’s version of the database, or you risk breaking your site.

Verify

Visit the live site’s address in a browser. Your pages load with the content you built locally, and uploaded images display, which confirms the files directory moved along with the database.

Variations

• Developer-grade deployments: teams that deploy with Git and configuration management follow the deployment workflow in the developer docs.
• Multiple copies of the same site: see Concept: Development Sites in the Drupal User Guide.

Related

• Back up your site before and after the move.
• Security checklist hardens a site before launch.
• How updates work keeps the live site current.