[ ← blog / ddev ](/) Jul 16, 2020  ·  \#ddev  ·  7 min read # Launching a Drupal 9 site on DDEV-Live Sunday, July 5th, [I did my livestream exploring DDEV-Live](https://youtu.be/5IGit6oXc-0). [DDEV-Live](https://ddev.com/ddev-live/) is the hosting counterpart of DDEV-Local. I use DDEV-Local as my local development stack, and I love its simplicity for running local environments with Docker. You may remember the company as DRUD - Destroy, Rebuild, Update, Destroy – and DDEV-Local as just DDEV. They have centralized on the DDEV brand name focusing on just the Local and Live products. ![DDEV-Live homepage](/sites/default/files/styles/large/public/2020-07/Screen%20Shot%202020-07-12%20at%2012.53.39%20PM.png?itok=x0RouiL7) There were a few hiccups while getting started – which I totally expect the first time trying new product! I often skipped ahead of some of the documentation, and the user interface (or command line) needs to expose a little bit more metadata (I'll explain later.) DDEV-Live has been an enterprise hosting environment, so the end user features are still being flushed out. All in all, I'm excited to keep using the product. To begin, you sign up with your email, GitHub or Google account. It's powered by [Firebase Authentication](https://firebase.google.com/products/auth). If you use [Brave browser](https://brave.com/gla077), you'll need to disable shields for this to work. During your account setup, you will setup your account name and organization name. **Be aware of what you set** as these will be needed later on. I kind of buzzed through and had a hiccup down the road (I didn't know my organization name.) ![DDEV-Live integration settings](/sites/default/files/styles/large/public/2020-07/Screen%20Shot%202020-07-07%20at%208.33.50%20PM.png?itok=Z1odl_pP) You work with DDEV-Live by connecting their GitHub App to your personal account or organization. There is a DDEV API token you can use for integrating with the command line tool in your continuous integration tool. From there, everything is done via the command-line. Their [Getting Started](https://docs.ddev.com/getting-started/) documentation shows how to install the command line. For macOS it is a Homebrew recipe. Once you have the GitHub App installed, you can authenticate with the command-line tool. ```bash ddev-live auth ``` The `auth` command will launch a browser. Since you are already logged into your DDEV dashboard, it should automatically complete the OAuth handshake and authenticate your local device. **However**, if you are like me, it did not launch the correct browser (my computer defaults to Chrome, but I actually use Brave. Long story, explained in my live stream.) If the browser launch does not work, you can explicitly provide your DDEV token ```bash ddev-live auth --token $DDEV_LIVE_TOKEN ``` A hindsight lesson: When I did `auth`, I should have specified my default organization using the `--default-org` flag. Organizations in DDEV-Live are like namespaces in Kubernetes. You can read more about them in the [DDEV-Live Organizations documentation](https://docs.ddev.com/organizations/). When I signed up, I set my org to `glamanate` thinking it was going to be my site name. Whoops! There currently isn't a user interface to revealing this information and luckily DDEV team members were on the call and helped bail me out. ![DDEV-Live Auth with default org](/sites/default/files/styles/large/public/2020-07/mglaman_Matts-MBP-2___.png?itok=1cWXKJUv) If you do not specify a default organization you will need to provide it with every command thereafter. This isn't too cumbersome if you are used to working with Kubernetes and having resources in different namespaces for each application. To create a site, you use the `ddev-live create` command. When you create a site, you provide the type of site you will be creating – Drupal, TYPO3, or WordPress. ```bash ~ » ddev-live create site --help Launch a new site Usage: ddev-live create site [command] Available Commands: drupal Create a Drupal site typo3 Create a TYPO3 site wordpress Create a WordPress site ``` When you create the site from the command line, you specify the site's name and the GitHub repository that contains the code for the site. Using the `--help` flag explains various settings when setting up your new site. For instance, here is the command that was required for creating a new Drupal 9 site from the Composer template provided in the [Local Development Guide on Drupal.org](https://www.drupal.org/docs/official_docs/en/_local_development_guide.html). ```bash ddev-live create site drupal \ ddev-live-d9 \ --github-repo mglaman/ddev-live-d9 \ --php-version=7.3 \ --drupal-version=9 \ --docroot web \ --run-composer-install ``` Here is a breakdown of what is going on with that command: - `ddev-live create site drupal`: We're creating a new site that is setup for hosting a Drupal site. - `ddev-live-d9`: This is our site name. - `--github-repo mglaman/ddev-live-d9`: This tells DDEV-Live to pull code from the GitHub repository `mglaman/ddev-live-d9.` - `--php-version=7.3`: This one is important! The default PHP version for Drupal is currently 7.2 and Drupal 9 requires 7.3. - `--docroot web`: When using the default Composer template, all assets that should be served by the web server exist in the `web` directory, like `index.php`. - `--run-composer-install`: This ensures that Composer is executed to install your dependencies during the build process for your site. You may also provide a `--branch` flag to specify what branch should be monitored for changes to deploy. There is also `--composer-args`, which allows you to pass arguments to `composer install` when your site is building. This can be used to ensure `--no-dev` is passed to prevent developer dependencies from installing. For example, the command could be expanded to support `--no-dev --prefer-dist --optimize-autoloader --apcu-autoloader --no-suggest --no-progress`. (This is my normal `composer install` argument for production builds.) You provide each argument without the dashes separated by a space. ```bash ddev-live create site drupal \ ddev-live-d9 \ --github-repo mglaman/ddev-live-d9 \ --php-version=7.3 \ --drupal-version=9 \ --docroot web \ --run-composer-install \ --composer-args no-dev prefer-dist optimize-autoloader apcu-autoloader no-suggest no-progress ``` After you create your site, you need to wait for it to deploy. You can monitor the status of your site using the `describe` command. **Note! If you are like me and forgot to configure anything, the `ddev-live config drupal` command has you covered.** I fixed my site's Composer build command to have all of those arguments using the following command: ``` ddev-live config drupal ddev-live-d9 --composer-args no-dev prefer-dist optimize-autoloader apcu-autoloader no-suggest no-progress ``` When we run `ddev-live describe site ddev-live-d9`, you get various information back about your site's deployment. ![DDEV-Live site describe details](/sites/default/files/styles/large/public/2020-07/Screen%20Shot%202020-07-12%20at%201.36.03%20PM.png?itok=QKXLSst5) DDEV-Live listens for pushes to your repository to trigger deployments, based on the branch for the site. I was able to trigger a deployment via a commit and kick off a Kubernetes deployment. There currently is no way to monitor a deployment or see ones currently in process. I had to just keep running `describe` on my site to see when healthy checks returned OK. I was able to make backups of my site's database and files so that I could pull them locally. Whenever you trigger a backup command, a remote job is created and a `describe` command is provided to check for the job's completion. Again, there is no user interface for tracking items in progress. You can only run the `describe` command to see what their current status may be. Here's the cool part: With DDEV-Local v15 ([just released](https://github.com/drud/ddev/releases/tag/v1.15.0)!) you can [integrate with DDEV-Live to work on your site locally](https://ddev.readthedocs.io/en/latest/users/providers/DDEV-Live/). This allows you to run `ddev config ddev-live` to specify what DDEV-Live site your local environment is for. Then, you just run `ddev pull` to get the DDEV-Live site's database and files imported locally! **Note, file sync is based on the last file backup.** One of the things I appreciate most: their openness to feedback. The dashboard provides a feedback form. Their command line even has a shortcut for launching this form: `ddev-live feedback`. ![DDEV-Live feedback form](/sites/default/files/styles/large/public/2020-07/Screen%20Shot%202020-07-13%20at%207.49.43%20PM.png?itok=Pz9G7vE6) Over all, it felt pretty nice. I haven't been playing with my Kubernetes cluster as much as I thought I would, so I'm basically burning money for no reason. At $15.00 a month for personal sites, that isn't too bad. Interested? Make sure you catch the live stream recording below. You can also use the coupon code **mglamanblog** to get 50% for your first month [when you sign up](https://dash.ddev.com/pricing) by July 24th. ![](/themes/custom/mglaman/images/headshot.webp)Thanks for reading I write about Drupal, PHP, and the quiet infrastructure behind large sites — caching, config, and testing. New posts land every week or two. [Subscribe via RSS →](/rss.xml) [About me →](/about-me) [← Older PHPStan Drupal and Drupal Check now on TideLift ](/blog/phpstan-drupal-and-drupal-check-now-tidelift) [Newer → Do you need a Functional test for that? ](/blog/do-you-need-functional-test)