Deploy Drupal 9
If you have been customizing your existing project as you go, now is the time to ensure all code is committed to Git and to run
git push to Platform.sh to your production branch. Platform.sh then builds your code, producing a read-only image of your application, and deploys it into a running cluster of containers.
You can view the process in the console or, if you aren't using a source integration, in your terminal after pushing. When the process is done, click the URL to see your site.
If you set up an integration to a repository that contained many pull requests with the
–build-pull-requests=false flag, you can now activate the current environment to complete your deployment.
$ platform environment:activate -e <ENVIRONMENT_NAME>
If you are creating a new site, visiting the site in your browser will trigger the Drupal installer.
Run through it as normal, but note that you will not be asked for the database credentials.
settings.platformsh.php file added earlier automatically provides the database credentials
and the installer is smart enough to not ask for them again.
Once the installer is complete you are presented with your new site.
If you are moving an existing site to Platform.sh, then in addition to code you also need to migrate your data. That means your database and your files.
First, obtain a database dump from your current site.
If you are using MySQL/MariaDB, then the
mysqldump command is all you need.
Save your dump file as
(Or any name, really, as long as it’s the same as you use below.)
Drupal has a number of database tables that are entirely useless when migrating and you’re better off excluding their data.
- If you’re using a database cache backend then you can and should exclude all
cache_*table data. On Platform.sh we recommend using Redis anyway, and the template described on the previous pages uses Redis automatically.
sessionstable’s data can also be excluded.
While you can trim the data out of these tables post-migration, that’s wasteful of both time and disk space, so it’s better to exclude that data to begin with.
Next, import the database into your Platform.sh site. The easiest way to do so is with the Platform.sh CLI.
platform sql -e production < database.sql
That connects to the database service on the
production environment, through an SSH tunnel, and runs the SQL import.
You first need to download your files from your current hosting environment, whatever that is.
The easiest way is likely with rsync, but consult your old host’s documentation.
This guide assumes that you have already downloaded
all of your user files to your local
files/user directory and your public files to
, but adjust accordingly for their actual locations.
platform mount:upload command provides a straightforward way to upload an entire directory to your site at once.
Under the hood, it uses an SSH tunnel and rsync, so it’s as efficient as possible.
(There is also a
platform mount:download command you can use to download files later.)
Run the following from your local Git repository root
--source path if needed
<BRANCH_NAME> to the branch you are using).
$ platform mount:upload -e <BRANCH_NAME> --mount src/main/resources/files/user --source ./files/user $ platform mount:upload -e <BRANCH_NAME> --mount src/main/resources/files/public --source ./files/public
Note that rsync is picky about its trailing slashes, so be sure to include those.
Your files and database are now loaded onto your Platform.sh production environment. When you make a new branch environment off of it, all of your data is fully cloned to that new environment so you can test with your complete dataset without impacting production.
Go forth and Deploy (even on Friday)!